[
https://issues.apache.org/jira/browse/WSCOMMONS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536729
]
Ajith Harshana Ranabahu commented on WSCOMMONS-264:
---------------------------------------------------
Hi Raymond /all
I've added a new feature (see commit 587136) to support your first case. Now
you can set a known schema map and that map will be queried if the
schemaLocation is not present. Also the the NPE when reolver returns null has
been resolved
Let me know whether the fix for the first case solves your last issue as well
> 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]
