using Xinclude with multi-core

[Peter Wolanin <pe...@acquia.com>]

I'm trying to take advantage of the Solr 1.4 Xinclude feature to
include a different xml fragment (e.g. a different analyzer chain in
schema.xml) for each core in a multi-core setup.  When the Xinclude
operates on a relative path, it seems to NOT be acting relative to the
xml file with the Xinlclude statement.  Using the jetty example, it
looks for a file in example/.

Is this a bug in the way Solr invokes Xinclude?  If not, is there a
variable that contains the instanceDir that can be used?
${solr.instanceDir} or ${solr/instanceDir}

DOMUtil.substituteProperties(doc, loader.getCoreProperties());

I see that I could potentially specify solrcore.properties,
http://wiki.apache.org/solr/SolrConfigXml#System_property_substitutionin
order to determine the correct based path, but this seems overly
complicated in terms of wht the useual use case would be for Xinclude?

-Peter

-- 
Peter M. Wolanin, Ph.D.
Momentum Specialist,  Acquia. Inc.
peter.wolanin@acquia.com

Re: using Xinclude with multi-core

[Chris Hostetter <ho...@fucit.org>]

: I'm trying to take advantage of the Solr 1.4 Xinclude feature to
: include a different xml fragment (e.g. a different analyzer chain in
: schema.xml) for each core in a multi-core setup.  When the Xinclude
: operates on a relative path, it seems to NOT be acting relative to the
: xml file with the Xinlclude statement.  Using the jetty example, it
: looks for a file in example/.

Peter: I know very little about XInclude, but based on your description of 
the problem i suspect it's bigger then just multi-core.

It sounds like the Xinclude processing is using the CWD to resolve all 
included files -- regardless of what SolrHome or the instancedir is.

Looking at Config.java, i suspect that DocumentBuilder *would* 
process relative XInclude paths properly if it know what the original 
filename of the XML Document was -- but we only give it an InputStream, so 
i supsect resolving relative the current working directly is it's fall 
back behavior.

This seems like an (anoying) bug in Solr.  Unfortunately i don't have an 
suggested fix or workarround for you...

https://issues.apache.org/jira/browse/SOLR-1656





-Hoss