Description
Interesting regression has been observed with JAXB 2.3.5 and 3.x: the CXF builds are failing with :
[ERROR] rt\wsdl\src\test\resources\schemas\wsdl\test-conf.xjb [25:88]: "http://schemas.xmlsoap.org/wsdl/" is not a part of this compilation. Is this a mistake for "file:core/src/main/resources/schemas/wsdl/wsdl.xsd"? com.sun.istack.SAXParseException2; systemId: file:/rt/wsdl/src/test/resources/schemas/wsdl/test-conf.xjb; lineNumber: 25; columnNumber: 88; "http://schemas.xmlsoap.org/wsdl/" is not a part of this compilation. Is this a mistake for "file:core/src/main/resources/schemas/wsdl/wsdl.xsd"? at com.sun.tools.xjc.reader.internalizer.Internalizer.reportError(Internalizer.java:570) at com.sun.tools.xjc.reader.internalizer.Internalizer.reportError(Internalizer.java:563) at com.sun.tools.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:206) at com.sun.tools.xjc.reader.internalizer.Internalizer.buildTargetNodeMap(Internalizer.java:335) at com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:116) at com.sun.tools.xjc.reader.internalizer.Internalizer.transform(Internalizer.java:77) at com.sun.tools.xjc.reader.internalizer.DOMForest.transform(DOMForest.java:429) at com.sun.tools.xjc.ModelLoader.buildDOMForest(ModelLoader.java:286) at com.sun.tools.xjc.ModelLoader.loadXMLSchema(ModelLoader.java:318) at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:121) at com.sun.tools.xjc.ModelLoader.load(ModelLoader.java:76) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at org.apache.cxf.maven_plugin.XSDToJavaRunner.loadModel(XSDToJavaRunner.java:224) at org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:174) at org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360) at org.apache.cxf.maven_plugin.XSDToJavaRunner.loadModel(XSDToJavaRunner.java:224) at org.apache.cxf.maven_plugin.XSDToJavaRunner.run(XSDToJavaRunner.java:174) at org.apache.cxf.maven_plugin.XSDToJavaRunner.main(XSDToJavaRunner.java:360)
It turned out, it is related to the change of how `systemId` is being passed through: previously, it was passed along with the `InputSource` in `DOMForest` by calling this method:
/**
* Parses an XML at the given location (
* and XMLs referenced by it) into DOM trees
* and stores them to this forest.
*
* @return the parsed DOM document object.
*/
public Document parse( String systemId, boolean root ) throws SAXException, IOException {
...
// but we still use the original system Id as the key.
return parse( systemId, is, root );
}
But the latest runtimes were changed to use this method instead:
public Document parse( InputSource source, boolean root ) throws SAXException {
if( source.getSystemId()==null )
throw new IllegalArgumentException();
return parse( source.getSystemId(), source, root );
}
As the result, the `systemId` was stopped to resolve in certain cases.
Attachments
Issue Links
- is depended upon by
-
CXF-8371 Support Jakarta EE 9.0+
-
- Closed
-
- links to