[
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.
> [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
