Open glassfishrobot opened 14 years ago
Reported by dkulp
dkulp said: Another (actually preferred) enhancement would be a way to configure in (via the options or similar) a custom InternalizationLogic object where we can provide a custom AbstractReferenceFinderImpl that could handle the schemaLocation mapping itself. That would allow us to wire in support for our catalogs and "internal" schemas and such instead of jumping out to the internet in some cases.
snajper said: updating status
Was assigned to snajper
This issue was imported from java.net JIRA JAXB-728
Invoking xjc programatically, if I pass an input schema that has a systemId of a "jar" url, such as:
jar:file:/home/dkulp/.m2/repository/net/tataryn/CXFSchemaRefProblemXSDJar/r1v0m0 /CXFSchemaRefProblemXSDJar-r1v0m0.jar!/telus/coreschemas/datatypes-base.xsd
or similar, and that xsd has an include like:
in it, the "voc.xsd" is not being resolved. The problem is in AbstractReferenceFinderImpl with the line:
String ref = new URI(locator.getSystemId()).resolve(new URI(relativeRef)).toString();
The URI class treats "jar" URL's as opaque (possibly a bug in URI class in the JDK). Thus, it always returns the "child" URI, which would just be "voc.xsd" in this case. A "workaround" for this can be something like:
URI base = new URI(locator.getSystemId()); String ref; if ("jar".equals(base.getScheme()) { ref = new URL(new URL(locator.getSystemId()), relativeRef).toString(); } else { ref = base.resolve(new URI(relativeRef)).toString(); }
That would fix it for the "jar" case, but it's possible that other schemes might want to do the same thing. Thus, another possible fix would be:
URI base = new URI(locator.getSystemId()); String ref; if (base.isOpaque()) { ref = new URL(new URL(locator.getSystemId()), relativeRef).toString(); } else { ref = base.resolve(new URI(relativeRef)).toString(); }
Environment
Operating System: All Platform: All
Affected Versions
[2.1.12]