[jira] Resolved: (WSCOMMONS-264) Provide extensibility to register pre-loaded XmlSchema instances with XmlSchemaCollection

["Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WSCOMMONS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ajith Harshana Ranabahu resolved WSCOMMONS-264.
-----------------------------------------------

    Resolution: Fixed

It seems this issue is solved - please reopen if you still find this insufficient in RC2

> Provide extensibility to register pre-loaded XmlSchema instances with XmlSchemaCollection
> -----------------------------------------------------------------------------------------
>
>                 Key: WSCOMMONS-264
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-264
>             Project: WS-Commons
>          Issue Type: Improvement
>          Components: XmlSchema
>            Reporter: Raymond Feng
>
> Hi,
> We currently use XmlSchema to load XSDs. To resolve the import/include directives using our schemes, we provide an implementation of 
> org.apache.ws.commons.schema.resolver.URIResolver and set it to org.apache.ws.commons.schema.XmlSchemaCollection. It works well if the 
> schemaLocation attribute for the <xsd:import> or <xsd:include> is set.
> Now we would like to handle the cases where the schemaLocation attribute is not present. For example, <xsd:import namespace="http://ns1"/>. Without the 
> schemaLocation, we resolve the import/include by namespace. In this case, we already have a map keyed by namespace for a list of XmlSchema objects loaded 
> from a catalog or other files and we want to reuse them. Would it be possible to open the XmlSchemaCollection.getSchema(SchemaKey) method so that 
> we can override/customize the behavior to associate existing XmlSchema instances to a SchemaKey? BTW, using a singleton of XmlSchemaCollection to 
> keep the schema map is not always feasible.
> Another observation is that a NPE will be thrown if the URIResolver.resolveEntity() returns null. Is there any way to disable the aggressive resolving/loading of import/include?
> Another use case:
> xsdA --> imports --> xsdC
> xsdB --> imports --> xsdC
> If we load xsdA and xsdB from two XmlSchemaCollections, then cannot share xsdC and xsdC will be loaded twice from two paths. Adding the extensisibility would allow us to share more efficiently too.
> rfeng@apache.org
> Raymond Feng
> Apache Tuscany 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org