Return-Path: Delivered-To: apmail-lucene-solr-user-archive@minotaur.apache.org Received: (qmail 66626 invoked from network); 14 Dec 2009 23:36:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 14 Dec 2009 23:36:43 -0000 Received: (qmail 56966 invoked by uid 500); 14 Dec 2009 23:36:41 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 56901 invoked by uid 500); 14 Dec 2009 23:36:40 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 56888 invoked by uid 99); 14 Dec 2009 23:36:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Dec 2009 23:36:40 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.69.42.181] (HELO radix.cryptio.net) (208.69.42.181) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Dec 2009 23:36:32 +0000 Received: by radix.cryptio.net (Postfix, from userid 1007) id 7C33771C33C; Mon, 14 Dec 2009 15:36:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by radix.cryptio.net (Postfix) with ESMTP id 7A89E71C230 for ; Mon, 14 Dec 2009 15:36:11 -0800 (PST) Date: Mon, 14 Dec 2009 15:36:11 -0800 (PST) From: Chris Hostetter To: solr-user@lucene.apache.org Subject: Re: using Xinclude with multi-core In-Reply-To: <2c138bed0911271403h35af4fd5vc8bbb1c0a677bde4@mail.gmail.com> Message-ID: References: <2c138bed0911271403h35af4fd5vc8bbb1c0a677bde4@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Checked: Checked by ClamAV on apache.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