Open glassfishrobot opened 10 years ago
Reported by lexi
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.
File: cd.zip Attached By: lexi
File: gml-v_3_1_1.zip Attached By: lexi
Was assigned to yaroska
This issue was imported from java.net JIRA JAXB-1045
Any progress on this?
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.