jaxb
  1. jaxb
  2. JAXB-942

Catalog with PUBLIC definition fails when using an episode

    Details

    • Type: Bug Bug
    • Status: In Progress
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.6
    • Fix Version/s: None
    • Component/s: xjc
    • Labels:
      None

      Description

      This issue is a result of analysis for MAVEN_JAXB2_PLUGIN-53.

      The problem is that using a catalog with PUBLIC definition fails when episode is used as well.

      I have a schema b.xsd which imports a schema a.xsd:

      <xsd:import namespace="http://maven-jaxb2-plugin/samples/episode/a" schemaLocation="a.xsd"/>
      

      The schema a.xsd is, however placed in a/a.xsd. This can be handled with the following catalog entry:

      PUBLIC "http://maven-jaxb2-plugin/samples/episode/a" "a/a.xsd"
      

      This works fine:

      xjc -catalog catalog.cat b.xsd
      

      Now assume we also have an episode JAR:

      a.jar!/META-INF/sun-jaxb.episode
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <bindings version="2.1" xmlns="http://java.sun.com/xml/ns/jaxb">
        <bindings scd="x-schema::tns" xmlns:tns="http://maven-jaxb2-plugin/samples/episode/a">
          <schemaBindings map="false">
            <package name="maven_jaxb2_plugin.samples.episode.a"/>
          </schemaBindings>
          <bindings scd="~tns:AType">
            <class ref="maven_jaxb2_plugin.samples.episode.a.AType"/>
          </bindings>
          <bindings scd="~tns:A1Type">
            <class ref="maven_jaxb2_plugin.samples.episode.a.A1Type"/>
          </bindings>
          <bindings scd="~tns:A2EnumType">
            <typesafeEnumClass ref="maven_jaxb2_plugin.samples.episode.a.A2EnumType"/>
          </bindings>
        </bindings>
      </bindings>
      

      Now this fails:

      xjc -extension -catalog catalog.cat b.xsd a.jar

      The catalog does not work:

      xjc -extension -catalog catalog.cat b.xsd a.jar
      parsing a schema...
      [ERROR] ...\test\a.xsd (Das System kann die angegebene Datei nicht finden) (eng. Could not find the file)
      unknown location
      
      Failed to parse a schema.

      I can provide a minimal test project which reproduces this. Attachments do not work. Via mail? (Please ping me: valikov at gmx.net)

        Activity

        Hide
        lexi added a comment -

        I did some debugging and found out that in case no binding files are used, model loading opts to "speculative mode"

        I traced it down to the DOMForest which calls the entity resolver with null publicId (whereas it is not null - the namespace is provided):

        DOMForest.java
        public Document parse( String systemId, boolean root ) throws SAXException, IOException {
        
                systemId = Options.normalizeSystemId(systemId);
        
                if( core.containsKey(systemId) )
                    // this document has already been parsed. Just ignore.
                    return core.get(systemId);
                
                InputSource is=null;
                
                // allow entity resolver to find the actual byte stream.
                if( entityResolver!=null )
        
        // HERE:
                    is = entityResolver.resolveEntity(null,systemId);
                if( is==null )
                    is = new InputSource(systemId);
                
                // but we still use the original system Id as the key.
                return parse( systemId, is, root );
            }
        
        

        If no episodes are provided, then no binding files are defined and ModelLoader opts to the "speculative" mode:

        ModelLoader.java
        public XSSchemaSet loadXMLSchema() throws SAXException {
        
                if( opt.strictCheck && !SchemaConstraintChecker.check(opt.getGrammars(),errorReceiver,opt.entityResolver, opt.disableXmlSecurity)) {
                    // schema error. error should have been reported
                    return null;
                }
        
                if(opt.getBindFiles().length==0) {
                    // no external binding. try the speculative no DOMForest execution,
                    // which is faster if the speculation succeeds.
                    try {
                        return createXSOMSpeculative();
                    } catch( SpeculationFailure _ ) {
                        // failed. go the slow way
                    }
                }
        
                // the default slower way is to parse everything into DOM first.
                // so that we can take external annotations into account.
                DOMForest forest = buildDOMForest( new XMLSchemaInternalizationLogic() );
                return createXSOM(forest, scdBasedBindingSet);
            }
        

        It seems to be something wrong with the DOMForest. It should not ignore the publicId.

        Show
        lexi added a comment - I did some debugging and found out that in case no binding files are used, model loading opts to "speculative mode" I traced it down to the DOMForest which calls the entity resolver with null publicId (whereas it is not null - the namespace is provided): DOMForest.java public Document parse( String systemId, boolean root ) throws SAXException, IOException { systemId = Options.normalizeSystemId(systemId); if ( core.containsKey(systemId) ) // this document has already been parsed. Just ignore. return core.get(systemId); InputSource is= null ; // allow entity resolver to find the actual byte stream. if ( entityResolver!= null ) // HERE: is = entityResolver.resolveEntity( null ,systemId); if ( is== null ) is = new InputSource(systemId); // but we still use the original system Id as the key. return parse( systemId, is, root ); } If no episodes are provided, then no binding files are defined and ModelLoader opts to the "speculative" mode: ModelLoader.java public XSSchemaSet loadXMLSchema() throws SAXException { if ( opt.strictCheck && !SchemaConstraintChecker.check(opt.getGrammars(),errorReceiver,opt.entityResolver, opt.disableXmlSecurity)) { // schema error. error should have been reported return null ; } if (opt.getBindFiles().length==0) { // no external binding. try the speculative no DOMForest execution, // which is faster if the speculation succeeds. try { return createXSOMSpeculative(); } catch ( SpeculationFailure _ ) { // failed. go the slow way } } // the default slower way is to parse everything into DOM first. // so that we can take external annotations into account. DOMForest forest = buildDOMForest( new XMLSchemaInternalizationLogic() ); return createXSOM(forest, scdBasedBindingSet); } It seems to be something wrong with the DOMForest. It should not ignore the publicId.
        Hide
        phax added a comment - - edited

        I'm having the same problem in 2.2.7.
        I was tracing it down to AbstractReferenceFinderImpl.startElement

        The call to abstract method "findExternalResource" only returns the specified XSD path but totally ignores the publicID of the item (if present). The implementation to this method is in com.sun.tools.xjc.reader.xmlschema.parser.XMLSchemaInternalizationLogic$ReferenceFinder

        And afterwards it seems to me, that the resolution of the artifact does not consider a catalog!
        -> In my case this leads to the problem that the catalog file must contain an absolute path instead of a relative path!

        Show
        phax added a comment - - edited I'm having the same problem in 2.2.7. I was tracing it down to AbstractReferenceFinderImpl.startElement The call to abstract method "findExternalResource" only returns the specified XSD path but totally ignores the publicID of the item (if present). The implementation to this method is in com.sun.tools.xjc.reader.xmlschema.parser.XMLSchemaInternalizationLogic$ReferenceFinder And afterwards it seems to me, that the resolution of the artifact does not consider a catalog! -> In my case this leads to the problem that the catalog file must contain an absolute path instead of a relative path!
        Hide
        lexi added a comment -

        Here's a pull request which fixed it:

        https://github.com/gf-metro/jaxb/pull/8

        Show
        lexi added a comment - Here's a pull request which fixed it: https://github.com/gf-metro/jaxb/pull/8
        Hide
        phax added a comment -

        Any progress? The pull request is there forever? I don't even get a response on my OCA request....

        Show
        phax added a comment - Any progress? The pull request is there forever? I don't even get a response on my OCA request....
        Hide
        maiden168 added a comment -

        Thanks for reminder. I'll ask someone to take a look on it next week, but no hard promises.
        There are always priorities and problems with resources.

        Show
        maiden168 added a comment - Thanks for reminder. I'll ask someone to take a look on it next week, but no hard promises. There are always priorities and problems with resources.

          People

          • Assignee:
            maiden168
            Reporter:
            lexi
          • Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated: