Solr
  1. Solr
  2. SOLR-1656

XInclude's are resolved relative CWD, not instance dir

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 3.1, 4.0-ALPHA
    • Component/s: None
    • Labels:
      None

      Description

      As noted on the mailing list, when an XInclude in a config files refrences a relative path, it's resolved relative the CWD of the servlet container, and not the instanceDir of the core...

      http://old.nabble.com/using-Xinclude-with-multi-core-to26548400.html#a26548400

      1. Support_SAX_SystemId_via_wrapping_InputStream.patch
        8 kB
        David Smiley
      2. SOLR-1656-mockup.patch
        15 kB
        Uwe Schindler
      3. SOLR-1656-fallback.patch
        2 kB
        Uwe Schindler
      4. SOLR-1656.patch
        27 kB
        Uwe Schindler
      5. SOLR-1656.patch
        49 kB
        Uwe Schindler
      6. SOLR-1656_Support_SAX_SystemId_via_wrapping_InputStream.patch
        3 kB
        David Smiley

        Issue Links

          Activity

          Hide
          Grant Ingersoll added a comment -

          Bulk close for 3.1.0 release

          Show
          Grant Ingersoll added a comment - Bulk close for 3.1.0 release
          Hide
          Yonik Seeley added a comment -

          Confirmed that XInclude (and fallback) work in zookeeper. Nice work!

          Show
          Yonik Seeley added a comment - Confirmed that XInclude (and fallback) work in zookeeper. Nice work!
          Hide
          Uwe Schindler added a comment -

          fallback fixed in trunk (1075079) and 3.x (1075081)

          Show
          Uwe Schindler added a comment - fallback fixed in trunk (1075079) and 3.x (1075081)
          Hide
          Uwe Schindler added a comment -

          Patch, will commit now to trunk and 3.x.

          Show
          Uwe Schindler added a comment - Patch, will commit now to trunk and 3.x.
          Hide
          Uwe Schindler added a comment -

          XInclude fallback does not work because ResourceLoader must throw IOException on missing file.

          Fixing this in SystemIdResolver

          Show
          Uwe Schindler added a comment - XInclude fallback does not work because ResourceLoader must throw IOException on missing file. Fixing this in SystemIdResolver
          Hide
          Yonik Seeley added a comment -

          About the ZooKeeper question: XInclude and all other things should now work with Zookeper. I have no local Cloud installation, so I could not test it

          If you have a normal solr instance with an xinclude somewhere under "conf", then one can just do this:

          java -Dbootstrap_confdir=./solr/conf -Dcollection.configName=myconf -DzkRun -jar start.jar
          

          That's just the first example in http://wiki.apache.org/solr/SolrCloud

          Show
          Yonik Seeley added a comment - About the ZooKeeper question: XInclude and all other things should now work with Zookeper. I have no local Cloud installation, so I could not test it If you have a normal solr instance with an xinclude somewhere under "conf", then one can just do this: java -Dbootstrap_confdir=./solr/conf -Dcollection.configName=myconf -DzkRun -jar start.jar That's just the first example in http://wiki.apache.org/solr/SolrCloud
          Hide
          Uwe Schindler added a comment -

          Committed trunk revision: 1075053

          About the ZooKeeper question: XInclude and all other things should now work with Zookeper. I have no local Cloud installation, so I could not test it, but with my changes all relative hrefs in XML config files should now be resolved through ZK, too, as SkSolrResourceLoader is used for resolving.

          Mark Miller, can you test this somehow? If it does not work, please reopen.

          Show
          Uwe Schindler added a comment - Committed trunk revision: 1075053 About the ZooKeeper question: XInclude and all other things should now work with Zookeper. I have no local Cloud installation, so I could not test it, but with my changes all relative hrefs in XML config files should now be resolved through ZK, too, as SkSolrResourceLoader is used for resolving. Mark Miller, can you test this somehow? If it does not work, please reopen.
          Hide
          Uwe Schindler added a comment -

          Committed 3.x revision: 1075044

          Show
          Uwe Schindler added a comment - Committed 3.x revision: 1075044
          Hide
          Uwe Schindler added a comment -

          Final patch:

          • Added a test for the resolver
          • Fixed more config files to use correct systemIds (cores config file)
          • changed URI scheme a little bit to use nicer looking authority component for absolute paths
          • hack in resolver for absolute-relative systemIds in HREfs (see comment)

          Will commit soon and port to trunk!

          Show
          Uwe Schindler added a comment - Final patch: Added a test for the resolver Fixed more config files to use correct systemIds (cores config file) changed URI scheme a little bit to use nicer looking authority component for absolute paths hack in resolver for absolute-relative systemIds in HREfs (see comment) Will commit soon and port to trunk!
          Hide
          Uwe Schindler added a comment -

          Sorry, last patch was outdated.

          Show
          Uwe Schindler added a comment - Sorry, last patch was outdated.
          Hide
          Uwe Schindler added a comment -

          Here is a new patch, redesigned:

          • The resolver was moved into a util class in common pkg. This resolver supports all types EntityResolver, URIResolver, XMLResolver used by inconsistent XML APIs to resolve systemIds
          • The backwards breaks were minimized (only in IndexSchema the InputStream was changed to InputSource, because Config needs that).
          • Not only xincludes use ResourceLoader, also XSLTResponseWriter takes care, so includes/imports of stylesheets are done by ResourceLoader
          • DIH also loads its config file and support xinclude from ResourceLoader. The API was changed to remove the stupid String containing the config file (that was crazy!)
          • DIH's XSL loader in XPathEntityProcessor was changed to also use ResourceLoader, before it always used CWD!!!
          • XInclude is only enabled, if a systemId is available

          I will wait a day until I commit, please review!

          Show
          Uwe Schindler added a comment - Here is a new patch, redesigned: The resolver was moved into a util class in common pkg. This resolver supports all types EntityResolver, URIResolver, XMLResolver used by inconsistent XML APIs to resolve systemIds The backwards breaks were minimized (only in IndexSchema the InputStream was changed to InputSource, because Config needs that). Not only xincludes use ResourceLoader, also XSLTResponseWriter takes care, so includes/imports of stylesheets are done by ResourceLoader DIH also loads its config file and support xinclude from ResourceLoader. The API was changed to remove the stupid String containing the config file (that was crazy!) DIH's XSL loader in XPathEntityProcessor was changed to also use ResourceLoader, before it always used CWD!!! XInclude is only enabled, if a systemId is available I will wait a day until I commit, please review!
          Hide
          Uwe Schindler added a comment -

          My last comment simply means, that enabling XInclude for ConfigParsers that work on InputStreams is broken (e.g. when a request comes in from network via http) because no SystemID. I simply want to change the code to disable xinclude for those parsers.

          I will work on my patch today and look for other parts in Solr where XInclude is used or complex XML files that support href-like. One example is DIH, which config file supports xinclude but has the same problem. Also XSLs loaded by xml response writer should use the custom EnityResolver.

          I will also make the patch almost backwards compatible.

          I will talk with Robert about including into 3.1, I don't see a problem.

          Show
          Uwe Schindler added a comment - My last comment simply means, that enabling XInclude for ConfigParsers that work on InputStreams is broken (e.g. when a request comes in from network via http) because no SystemID. I simply want to change the code to disable xinclude for those parsers. I will work on my patch today and look for other parts in Solr where XInclude is used or complex XML files that support href-like. One example is DIH, which config file supports xinclude but has the same problem. Also XSLs loaded by xml response writer should use the custom EnityResolver. I will also make the patch almost backwards compatible. I will talk with Robert about including into 3.1, I don't see a problem.
          Hide
          David Smiley added a comment -

          Uwe, I'm trying to parse your last comment (without having looked at your patch), and it's unclear if you're saying "xinclude here is broken" after your patch still or if you fixed that somehow.

          Is some fix, either mine or the more comprehensive Uwe fix, going to make it into 3.1?

          Show
          David Smiley added a comment - Uwe, I'm trying to parse your last comment (without having looked at your patch), and it's unclear if you're saying "xinclude here is broken" after your patch still or if you fixed that somehow. Is some fix, either mine or the more comprehensive Uwe fix, going to make it into 3.1?
          Hide
          Uwe Schindler added a comment -

          After thinking a little bit about it, I found out that supporting XInclude at all for InputStream-only resources is broken and also a security leak and should be switched off:
          With my patch all SolrConfigs/SolrSchemas are correctly loaded using InputSource. But the Config base class is also used e.g. for parsing some requests where the XML comes from network as InputStream only. Supporting xinclude here is broken, as this network stream has no systemId, so I would simply disable xinclude and the EntityResolver if Config class only gets an InputStream instead of InputSource. Also it should not be possible to load arbitrary files from the filesystem referenced by a xml file in a network stream (this is somehow a security leak).
          After making the whole thing separate for InputSource and InputStreanm, it could also easily be made backwards compatible, as the InputStream methods are separate and support no xinclude and are not.

          Show
          Uwe Schindler added a comment - After thinking a little bit about it, I found out that supporting XInclude at all for InputStream-only resources is broken and also a security leak and should be switched off: With my patch all SolrConfigs/SolrSchemas are correctly loaded using InputSource. But the Config base class is also used e.g. for parsing some requests where the XML comes from network as InputStream only. Supporting xinclude here is broken, as this network stream has no systemId, so I would simply disable xinclude and the EntityResolver if Config class only gets an InputStream instead of InputSource. Also it should not be possible to load arbitrary files from the filesystem referenced by a xml file in a network stream (this is somehow a security leak). After making the whole thing separate for InputSource and InputStreanm, it could also easily be made backwards compatible, as the InputStream methods are separate and support no xinclude and are not.
          Hide
          Uwe Schindler added a comment -

          I forgot: This patch currently hides some deprecated methods in SolrResourceLoader by making them private. This is done to check that no place in solr uses the old methods anymore.

          Show
          Uwe Schindler added a comment - I forgot: This patch currently hides some deprecated methods in SolrResourceLoader by making them private. This is done to check that no place in solr uses the old methods anymore.
          Hide
          Uwe Schindler added a comment - - edited

          Here is a first mockup (branch_3.x like the previous patch) of the version with EntityResolver.

          This patch has some backwards breaks, because for XML files it is always broken to parse without a system identifier, so the ctors of SolrSchema and SolrConfig should not take InputStream but more a InputSource wrapper. With this patch everything compiles and tests and resolves correctly, but plugins using old methods may fail (needs review).

          How it works:
          The system identifier is no longer a plain filename with path, it gets initialized using a custom URI scheme "solrres:". This scheme is resolved using the EntityResolver that utilizes SolrResourceLoader. As long as somebody only gives relative URLs in XIncludes or anywhere else (this is also extendable to other places, not only xinclude, e.g. external XML entities inside XSLs, config of DIH,...), the files are staying using this scheme and are resolved by the custom EntityResolver. As soon as scheme changes, the default resolver is used.

          Because of this, the good thing is, that somebody can still use absolute filesystem URLs or even external URLs in the xincludes, by using full schemed URIs like file:///my/absolute/path.

          Other places in Solr that load XML and support Xinclude must also changed to this, currently almost every place where solr loads XML files from ResourceLoader using InputStreams are broken.

          Questionable is also backwards compatibibility. Ideally there should be a loadResourceAsInputSource() method in ResourceLoader so DIH can also use it, which would also break backwards (interface!).

          This patch is currently only for review about the idea. Comments welcome!

          Show
          Uwe Schindler added a comment - - edited Here is a first mockup (branch_3.x like the previous patch) of the version with EntityResolver. This patch has some backwards breaks, because for XML files it is always broken to parse without a system identifier, so the ctors of SolrSchema and SolrConfig should not take InputStream but more a InputSource wrapper. With this patch everything compiles and tests and resolves correctly, but plugins using old methods may fail (needs review). How it works: The system identifier is no longer a plain filename with path, it gets initialized using a custom URI scheme "solrres:". This scheme is resolved using the EntityResolver that utilizes SolrResourceLoader. As long as somebody only gives relative URLs in XIncludes or anywhere else (this is also extendable to other places, not only xinclude, e.g. external XML entities inside XSLs, config of DIH,...), the files are staying using this scheme and are resolved by the custom EntityResolver. As soon as scheme changes, the default resolver is used. Because of this, the good thing is, that somebody can still use absolute filesystem URLs or even external URLs in the xincludes, by using full schemed URIs like file:///my/absolute/path . Other places in Solr that load XML and support Xinclude must also changed to this, currently almost every place where solr loads XML files from ResourceLoader using InputStreams are broken. Questionable is also backwards compatibibility. Ideally there should be a loadResourceAsInputSource() method in ResourceLoader so DIH can also use it, which would also break backwards (interface!). This patch is currently only for review about the idea. Comments welcome!
          Hide
          Uwe Schindler added a comment -

          I will work on a patch doing this today.

          Show
          Uwe Schindler added a comment - I will work on a patch doing this today.
          Hide
          Uwe Schindler added a comment -

          Will it work if the included file resides in ZooKeeper?

          That's exactly the problem I am talking about. With my solution it would work if the files can be loaded by the URL with a custom URLConnection class. With David's patch that is attached to this issue, it will not work at all.

          The most complete version would be to wrap the SolrResourceLoader as org.xml.sax.EntityResolver and javax.xml.transform.URIResolver.

          Show
          Uwe Schindler added a comment - Will it work if the included file resides in ZooKeeper? That's exactly the problem I am talking about. With my solution it would work if the files can be loaded by the URL with a custom URLConnection class. With David's patch that is attached to this issue, it will not work at all. The most complete version would be to wrap the SolrResourceLoader as org.xml.sax.EntityResolver and javax.xml.transform.URIResolver.
          Hide
          Jan Høydahl added a comment -

          Will it work if the included file resides in ZooKeeper?

          Show
          Jan Høydahl added a comment - Will it work if the included file resides in ZooKeeper?
          Hide
          Uwe Schindler added a comment -

          Hoss:

          I'm not positive, believe we could actually take this further by using ClassLoader.getResource() to generate a systemId for items pulled from the classpath as well (but i'm not sure if hte resulting URLs would be of any use to the DocumentBuilder if it doesn't also use the SolrResourceLoader)

          That's perfectly fine, all XML parsers support any URL that java's URL class can load. To passing new InputSource(URL.toString()) always works with all known parsers (see above).

          Show
          Uwe Schindler added a comment - Hoss: I'm not positive, believe we could actually take this further by using ClassLoader.getResource() to generate a systemId for items pulled from the classpath as well (but i'm not sure if hte resulting URLs would be of any use to the DocumentBuilder if it doesn't also use the SolrResourceLoader) That's perfectly fine, all XML parsers support any URL that java's URL class can load. To passing new InputSource(URL.toString()) always works with all known parsers (see above).
          Hide
          Uwe Schindler added a comment -

          This path at least fixes the CWD problem in an non-intrusive way using a interface hack. I think that's perfectly fine to preserve the SystemID along with the InputStream.

          Problem is that the XML handling is a little bit inconsistent, because it currently only work for files and only if the files are in exact same directory. Theoretically, it should be possible that a XML file that is in the conf folder (which is part of the classpath) can load a file from the lib folder (which is also part of the resource classpath and should work with a relative filename only path) or even from inside a JAR file (if the java package name == classpath directory is identical).

          This could only be solved by e.g. supplying a method RessourceLoader.asFooBarResolver that returns a class that implements both org.xml.sax.EntityResolver, javax.xml.transform.URIResolver (to work with either SAX and TRAX) and delegates all requests to the underlying classloader. Example could be taken from http://www.ibm.com/developerworks/xml/library/x-tipentres.html (warning: this example is not correct, but goes into right direction).

          Another solution might be to not pass streams around, but simply feed the xml parser with the URL.toString() returned by ClassLoader.getResource(). This would also work with JAR files (I use this quite often in my code to parse XSL or other XML files in the JAR file of my programs):

          final URL url=MyClass.class.getResource("myXSLTFile.xslt");
          if (url == null) throw new FileNotFoundException();
          final Templates templates = transformerFactory.newTemplates(new StreamSource(t.toString()));
          

          This would also successfully load relative resources, but not accross JAR files or different dirs (so "./anyfile.xml" would only find the file if its in same java package in same JAR files but not if the file is in a different JAR file or other classpath entry in same package).

          Show
          Uwe Schindler added a comment - This path at least fixes the CWD problem in an non-intrusive way using a interface hack. I think that's perfectly fine to preserve the SystemID along with the InputStream. Problem is that the XML handling is a little bit inconsistent, because it currently only work for files and only if the files are in exact same directory. Theoretically, it should be possible that a XML file that is in the conf folder (which is part of the classpath) can load a file from the lib folder (which is also part of the resource classpath and should work with a relative filename only path) or even from inside a JAR file (if the java package name == classpath directory is identical). This could only be solved by e.g. supplying a method RessourceLoader.asFooBarResolver that returns a class that implements both org.xml.sax.EntityResolver, javax.xml.transform.URIResolver (to work with either SAX and TRAX) and delegates all requests to the underlying classloader. Example could be taken from http://www.ibm.com/developerworks/xml/library/x-tipentres.html (warning: this example is not correct, but goes into right direction). Another solution might be to not pass streams around, but simply feed the xml parser with the URL.toString() returned by ClassLoader.getResource(). This would also work with JAR files (I use this quite often in my code to parse XSL or other XML files in the JAR file of my programs): final URL url=MyClass.class.getResource( "myXSLTFile.xslt" ); if (url == null ) throw new FileNotFoundException(); final Templates templates = transformerFactory.newTemplates( new StreamSource(t.toString())); This would also successfully load relative resources, but not accross JAR files or different dirs (so "./anyfile.xml" would only find the file if its in same java package in same JAR files but not if the file is in a different JAR file or other classpath entry in same package).
          Hide
          David Smiley added a comment -

          I provided an updated patch:

          • Using Hoss's suggestion of a HasSystemId interface. However note I couldn't do away with the InputStreamWithSystemId class since Hoss's suggestion of an anonymous inner class doesn't allow extending and implementing an interface at the same time.
          • Added documentation of file.toURI().toASCIIString(), which is per rule specified in RFC 2396. I don't claim credit for knowing this, I stole this comment and code out of the JDK in StreamResult.java.
          • Updated test to not include the hack of copying the resource to the CWD.

          Is this going to make it into 3.1?

          Show
          David Smiley added a comment - I provided an updated patch: Using Hoss's suggestion of a HasSystemId interface. However note I couldn't do away with the InputStreamWithSystemId class since Hoss's suggestion of an anonymous inner class doesn't allow extending and implementing an interface at the same time. Added documentation of file.toURI().toASCIIString(), which is per rule specified in RFC 2396. I don't claim credit for knowing this, I stole this comment and code out of the JDK in StreamResult.java. Updated test to not include the hack of copying the resource to the CWD. Is this going to make it into 3.1?
          Hide
          Robert Muir added a comment -

          I totally missed this issue... i've been fighting with this in the tests myself.

          I think we should fix this issue in 3.x, though I don't have the background to
          review your patch (at a glance the toASCIIString etc makes me nervous,
          but i have no idea whats going on)

          Show
          Robert Muir added a comment - I totally missed this issue... i've been fighting with this in the tests myself. I think we should fix this issue in 3.x, though I don't have the background to review your patch (at a glance the toASCIIString etc makes me nervous, but i have no idea whats going on)
          Hide
          David Smiley added a comment -

          It would be really nice to get this into the next version (3.x). If a committer agrees, can we get the "fix version" in JIRA set?

          Show
          David Smiley added a comment - It would be really nice to get this into the next version (3.x). If a committer agrees, can we get the "fix version" in JIRA set?
          Hide
          Joachim Martin added a comment - - edited

          I'm having a similar problem with using XInclude to import a transformers.js script file in DataImportHandler:

          <script xmlns:xi="http://www.w3.org/2001/XInclude">
          <xi:include parse="text" href="file:transformers.js"/>
          </script>

          At runtime, the XML parser looks for this in my solr directory, not parallel to my db-data-config.xml (in the core/conf directory).

          Having the source for script transformers in a separate js file allows me to use an IDE to check syntax, etc- very helpful.

          [I'm assuming this is the same problem, but not sure]

          Show
          Joachim Martin added a comment - - edited I'm having a similar problem with using XInclude to import a transformers.js script file in DataImportHandler: <script xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include parse="text" href="file:transformers.js"/> </script> At runtime, the XML parser looks for this in my solr directory, not parallel to my db-data-config.xml (in the core/conf directory). Having the source for script transformers in a separate js file allows me to use an IDE to check syntax, etc- very helpful. [I'm assuming this is the same problem, but not sure]
          Hide
          David Smiley added a comment -

          I thought of making a SolrResourceLoader.openResourceAsInputSource(String) and it wasn't clear earlier what sort of arrangement should exist between providers of InputSource objects and their consumers with regard to cleanup. (i.e. closing streams). So I just read the javadoc now. It seems to me that this method could be supported but we'd create the input stream on the fly via extending InputSource and doing the work in the getter. We don't want to create the stream if nobody calls it (even if we know that our particular consumer happens to call it and close it). Apparently the caller of the getInputStream is supposed to close it so perhaps this means we don't even need to close it in the Config constructor since the doc builder parse() method will.

          Show
          David Smiley added a comment - I thought of making a SolrResourceLoader.openResourceAsInputSource(String) and it wasn't clear earlier what sort of arrangement should exist between providers of InputSource objects and their consumers with regard to cleanup. (i.e. closing streams). So I just read the javadoc now. It seems to me that this method could be supported but we'd create the input stream on the fly via extending InputSource and doing the work in the getter. We don't want to create the stream if nobody calls it (even if we know that our particular consumer happens to call it and close it). Apparently the caller of the getInputStream is supposed to close it so perhaps this means we don't even need to close it in the Config constructor since the doc builder parse() method will.
          Hide
          Hoss Man added a comment -

          David: Interesting Idea. i must admit that while it feels very dirty, it's simplicity has some appeal.

          I'm not positive, believe we could actually take this further by using ClassLoader.getResource() to generate a systemId for items pulled from the classpath as well (but i'm not sure if hte resulting URLs would be of any use to the DocumentBuilder if it doesn't also use the SolrResourceLoader)

          Personally I think we should just bite the bullet and:

          • implement a new SolrResourceLoader.openResourceAsInputSource(String)
          • add the necessary constructors to start instantiating Config related options (SolrConfig, IndexSchema, etc) from InputSources

          what appeals to me about your idea is that it wouldn't conflict with adding support for InputSource, and could work as a nice safety net for code that might use SolrResourceLoader to get an InputStream even if we had a new method for getting InputSources.

          (the one key change i might suggest is to replace your InputStreamWithSystemId class with a one method marker interface "SystemIdable" and then use anonymous classes that implement that method – it seems a little cleaner, and allows for the possibility of decorating other things with systemIds ... like Readers perhaps)

          Show
          Hoss Man added a comment - David: Interesting Idea. i must admit that while it feels very dirty, it's simplicity has some appeal. I'm not positive, believe we could actually take this further by using ClassLoader.getResource() to generate a systemId for items pulled from the classpath as well (but i'm not sure if hte resulting URLs would be of any use to the DocumentBuilder if it doesn't also use the SolrResourceLoader) Personally I think we should just bite the bullet and: implement a new SolrResourceLoader.openResourceAsInputSource(String) add the necessary constructors to start instantiating Config related options (SolrConfig, IndexSchema, etc) from InputSources what appeals to me about your idea is that it wouldn't conflict with adding support for InputSource, and could work as a nice safety net for code that might use SolrResourceLoader to get an InputStream even if we had a new method for getting InputSources. (the one key change i might suggest is to replace your InputStreamWithSystemId class with a one method marker interface "SystemIdable" and then use anonymous classes that implement that method – it seems a little cleaner, and allows for the possibility of decorating other things with systemIds ... like Readers perhaps)
          Hide
          David Smiley added a comment -

          Attached is a patch implementing this. This patch is against r941377.

          Show
          David Smiley added a comment - Attached is a patch implementing this. This patch is against r941377.
          Hide
          Hoss Man added a comment -

          I may be very wrongly informing but using ...

          I'm sure you are correct, but as i mentioned, Config only has an InputStream when it instantiates the DocumentBuilder. (hence: non trivial fix)

          Show
          Hoss Man added a comment - I may be very wrongly informing but using ... I'm sure you are correct, but as i mentioned, Config only has an InputStream when it instantiates the DocumentBuilder. (hence: non trivial fix)
          Hide
          Paul Libbrecht added a comment -

          I may be very wrongly informing but using

          i = new InputSource(<theInputStream>);
          i.setSystemId(file.toURL().getExternalForm());

          is a recipe that has worked many times and allows relative resolution.

          new InputSource(file.toURL())

          should as well.

          paul

          Show
          Paul Libbrecht added a comment - I may be very wrongly informing but using i = new InputSource(<theInputStream>); i.setSystemId(file.toURL().getExternalForm()); is a recipe that has worked many times and allows relative resolution. new InputSource(file.toURL()) should as well. paul
          Hide
          Hoss Man added a comment -

          The probably is probably caused by the default behavior of DocumentBuilder when it doesn't know the filename of the XML it is parsing – Config.java only provides an InputStream

          Show
          Hoss Man added a comment - The probably is probably caused by the default behavior of DocumentBuilder when it doesn't know the filename of the XML it is parsing – Config.java only provides an InputStream

            People

            • Assignee:
              Uwe Schindler
              Reporter:
              Hoss Man
            • Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development