You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Raymond Feng (JIRA)" <ji...@apache.org> on 2007/10/17 21:37:50 UTC
[jira] Created: (WSCOMMONS-264) Provide extensibility to register
pre-loaded XmlSchema instances with XmlSchemaCollection
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
[jira] Commented: (WSCOMMONS-264) Provide extensibility to register
pre-loaded XmlSchema instances with XmlSchemaCollection
Posted by "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
[jira] Commented: (WSCOMMONS-264) Provide extensibility to register
pre-loaded XmlSchema instances with XmlSchemaCollection
Posted by "Ajith Harshana Ranabahu (JIRA)" <ji...@apache.org>.
[ 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.
> 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
[jira] Resolved: (WSCOMMONS-264) Provide extensibility to register
pre-loaded XmlSchema instances with XmlSchemaCollection
Posted by "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