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

["Raymond Feng (JIRA)" <ji...@apache.org>]

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

Raymond Feng commented on WSCOMMONS-264:
----------------------------------------

Hi, Ajith.

Thank you for working on this issue. Your fix paritially solves the problem 
but I am greedy to see more flexiblity here.

At this moment, the XmlSchemaCollection is a final class and most of its 
methods are not public or protected. The following two methods are of 
interests too.

org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(String, String, 
String, argetNamespaceValidator);
org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(String, String, 
TargetNamespaceValidator);

If they are relaxed a bit to be protected, we can subclass it to take over 
more controls, such as:

1) Resolve a namespace (without schemaLocation) to a pre-loaded XmlSchema 
(the schemaKey will be (ns, null)).
2) Resolve a schema key to another XmlSchema.

Thanks,
Raymond



> 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