1 Reply Latest reply on Jul 25, 2005 1:17 PM by starksm64

    JBossEntityResolver updates needed

    starksm64

      The current hard-coded publicID to dtd/xsd mapping in the JBossEntityResolver needs to be externalized to allow for augmenting with user schemas. I created the following feature request issue:

      http://jira.jboss.com/jira/browse/JBAS-2038

      The whole publicID/systemID/namespaceURI resolution behavior needs to be consistent across the various xml contexts. As I mention in the case I have not gotten the xml catalog resolver from apache to work as I would like, but I don't see a problem with using the xml catalog syntax for the externalization of the mappings.

      I need some feedback on how schemas are being resolved today in webservices and the like along with how this need to change with the introduction of jaxb.

        • 1. Re: JBossEntityResolver updates needed
          starksm64

          As of the current head/4.0 (for 4.0.3) jbossxb schema resolution behavior, there is a DefaultSchemaResolver implementation of org.jboss.xb.binding.sunday.unmarshalling.SchemaBindingResolver that uses a JBossEntityResolver instance. The resolution logic of the SchemaBinding resolve(String nsUri, String localName, String baseURI, String schemaLocation) call is:


          Using the nsUri as the systemID in the JBossEntityResolver.resolve(publicID, systemID) call. Looking at how we currently have some j2ee1.4 schemas registered, it looks like the first call should be to use the nsUri as the publicID
          Use the schemaLocation as the systemID in the JBossEntityResolver.resolve(publicID, systemID) call.

          If the schema is still not found, and the baseURI is not null, the xsd is located using a URL created from: URL(baseURI, schemaLocation).

          Otherwise, if the baseURI is null, the xsd is located using a URL created from the schemaLocation.