Open Tomas-Kraus opened 9 years ago
@glassfishrobot Commented Reported by lexi
@glassfishrobot Commented lexi said: Please consider a fix in the https://github.com/gf-metro/jaxb/pull/7
The problem here is that when the entity resolver resolves some systemId, you get an input source with the stream AND a resolved systemId. Subsequent resolutions (when you for instance have an import or an include) will use this resolved system id. This may result in some schemas addressed by an unresolved and by a resolved system id - despite being placed in the same local source.
The fix is simple: when resolving, only provide the stream and don't change the system id (or public id) of the input source. This still works well - parsers take XML from the stream. And this corrects the problem since system id does not change.
I understand that we're talking customer-facing interface here so you probably have to carefully consider if you apply the fixes or not. I am persuaded that what I propose is the correct behaviour, so I will want to fix it anyway (in maven-jaxb2-plugin, at least). I think I can make workarounds via the entity resolver for #1044 and #1045 as it is basically the entity resolver logic which is changed here. What I can't do is #1046 since it addresses the interna of the DOMForest which is not accessible. But I think this fix is not dangerous at all.
Please let me know what you think of the fixes and if we can work them into the XJC release.
@glassfishrobot Commented File: cd.zip Attached By: lexi
@glassfishrobot Commented File: gml-v_3_1_1.zip Attached By: lexi
@glassfishrobot Commented Was assigned to yaroska
@glassfishrobot Commented This issue was imported from java.net JIRA JAXB-1045
@bgedik Commented Any progress on this?
Should I provide a pull request to fix this?
@highsource You are most welcome to 👍
@bravehorsie Do I need to sign some CLA? I've signed some CLA with Sun or Oracle ages ago.
@bravehorsie I'd like to add a test for my three schemas + catalog file first. Where should I put them in the project? I see almost none XJC tests (which is surprizing).
So that I don't lose the fix code again.
Below are the patches I used to fix #1045 back then:
@highsource You need to sign Eclipse ECA and sign off the commits for check to pass.
@highsource
I'd like to add a test for my three schemas + catalog file first. Where should I put them in the project? I see almost none XJC tests (which is surprizing).
I don't have aged knowledge of JAXB history but I don't remember there were any tests other than for Ant tasks (xjc/src/test/java) ever. You could put your tests along there.
This is somewhat complex setup, please take a look at the prepared example (attached) first.
I am trying to do a clean compilation of the GML 3.1.1 schema using catalogs and binding files.
I've created local copies of files in the w3c and ogc folders and rewrite URLs using the following catalog file:
In the GML schema there is one schema which imports SMIL via the absolute URL:
My understanding is that http://schemas.opengis.net/gml/3.1.1/smil/smil20.xsd will be resolved to ogc/gml/3.1.1/smil/smil20.xsd via catalog.
The smil20.xsd imports smil20-language.xsd via relative URL:
The smil20-language.xsd imports the smil20.xsd also via relative URL:
When I try to compile this I get the following stream of errors:
Note that XJC complains about the identical URLs, also references the same lines (however in a wrong order which is a bit weird).
If I change both of the relative URLs in the SMIL schemas to absolute URLs, it does work. Of course, I don't want this workaround as I don't want to patch external schemas.
I've also reproduced it on a "reduced" test case with simple schemas (see the cd.zip attachment).
The problem arises only if bindings files are used. When compiling without bindings, it works (see success.bat and failure.bat in cd.zip). failure.bat gives the following error trace:
Lines are quite interesting. The element 'd' is reported two times on the same line. The type 'DType' is reported two times - one on the opening <complexType ...> tag of the type and once on the closing tag:
My guess is that the graph:
somehow causes problems with schema 2. I think the problem might be different paths to schema 2. The URLs are finally rewritten via catalog to the same URL but the same document gets parsed two times.
This is quite a showstopper for me at the moment. I am forced to patch schemas on a very big scale, which is extremely ugly.