Woden
  1. Woden
  2. WODEN-14

Use XML Catalog To Improve Performance and Enable Offline Work

    Details

    • Type: New Feature New Feature
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Parser
    • Labels:
      None

      Description

      Woden currently retrieves XML schemas from the Internet each time it performs a validator. This causes a multisecond performance degradation and prevents validation from working when there is no Internet access.

      Woden should use an XML catalog to resolve references to Internet resources. There should be an API for controlling the XML catalog so that Woden can be imbedded in other systems, such as Eclipse and Ant, that provide XML catalogs.

      The XML catalog should be consulted when resolving all resource requests, e.g. for XML schema or WSDL.

      1. ASF.LICENSE.NOT.GRANTED--lauri_carlson.vcf
        0.1 kB
        Lauri Carlson
      2. ASF.LICENSE.NOT.GRANTED--lauri_carlson.vcf
        0.1 kB
        Lauri Carlson
      3. sample.zip
        5 kB
        Graham Turrell
      4. woden14fileURLpath.txt
        3 kB
        Graham Turrell
      5. woden-14-patch1.txt
        29 kB
        Graham Turrell
      6. woden-14-patch3.txt
        160 kB
        Graham Turrell
      7. woden14-patch4all.txt
        237 kB
        Graham Turrell
      8. woden-14-patch5.txt
        16 kB
        Graham Turrell
      9. woden14SimpleURIResolvertest.txt
        180 kB
        Graham Turrell
      10. woden14SimpleURIResolverTest.txt
        1 kB
        Graham Turrell
      11. woden14srcpatch2.txt
        160 kB
        Graham Turrell

        Activity

        Hide
        Lawrence Mandel added a comment -

        I think the correct support will be to create an extensible URI resolver in Woden. (Xerces has this type of support and it's been very useful.) This will allow any system using Woden to customize resolution without limiting them to a catalog.

        The Woden Ant task can make use of the URI resolver to contribute the content of an xmlcatalog element.

        Show
        Lawrence Mandel added a comment - I think the correct support will be to create an extensible URI resolver in Woden. (Xerces has this type of support and it's been very useful.) This will allow any system using Woden to customize resolution without limiting them to a catalog. The Woden Ant task can make use of the URI resolver to contribute the content of an xmlcatalog element.
        Hide
        Graham Turrell added a comment -

        The framework to be implemented will be a simplified version of the XMLEntityResolver found in Xerces. The Xerces framework can resolve any deemed "XML Entity". For our purposes we are interested in resolving just URIs. If anyone believes the scope of the framework should be wider than URI/URL resolution then now is a good time to say! This JIRA however is URI specific.

        The framework will have the full extensibility capabilities of the Xerces resolver model: any resolver mechanism (that conforms to the API) may be plugged in to woden as its resolver. I intend to supply and bundle a default SimpleResolver. Provision will be made for OASIS XML Catalogs to be plugged in as the resolving mechanism, specifically that within the XML Commons Resolver 1.1 (resolver.jar), and wrapper classes provided as an API (as it is with Xerces).

        Further comments very welcome!

        Show
        Graham Turrell added a comment - The framework to be implemented will be a simplified version of the XMLEntityResolver found in Xerces. The Xerces framework can resolve any deemed "XML Entity". For our purposes we are interested in resolving just URIs. If anyone believes the scope of the framework should be wider than URI/URL resolution then now is a good time to say! This JIRA however is URI specific. The framework will have the full extensibility capabilities of the Xerces resolver model: any resolver mechanism (that conforms to the API) may be plugged in to woden as its resolver. I intend to supply and bundle a default SimpleResolver. Provision will be made for OASIS XML Catalogs to be plugged in as the resolving mechanism, specifically that within the XML Commons Resolver 1.1 (resolver.jar), and wrapper classes provided as an API (as it is with Xerces). Further comments very welcome!
        Hide
        Graham Turrell added a comment -

        This patch provides the new URI Resolver framework and a sample URI resolver implementation (SimpleURIResolver). I will shortly post some usage instructions, sample files and ultimately unit testcases so it can be put through its paces. Meanwhile John K has kindly offered to create a WODEN-14 branch from this patch and be involved in its review. All comments very welcome though!!

        Show
        Graham Turrell added a comment - This patch provides the new URI Resolver framework and a sample URI resolver implementation (SimpleURIResolver). I will shortly post some usage instructions, sample files and ultimately unit testcases so it can be put through its paces. Meanwhile John K has kindly offered to create a WODEN-14 branch from this patch and be involved in its review. All comments very welcome though!!
        Hide
        Graham Turrell added a comment -

        Here is detail on the patch - and at the end how to run the sample:

        This patch includes a framework for allowing resolution of any URI found in the source document(s). The framework allows for any conformant URI resolver implementation (ie implement the URIResolver interface) to be "plugged-in" at runtime. A simple default resolver implementation is provided (SimpleURIResolver).
        The framework has been incorporated into both the DOM and the OM parsers.

        Packages:
        Two new packages - org.apache.woden.resolver (API : framework classes, interfaces and concrete implementations) and org.apache.woden.internal.resolver (resolver helper classes).

        org.apache.woden.resolver contains:

        ? URIResolver interface
        ? SimpleURIResolver
        ? XMLCatalogURIResolver

        org.apache.woden.internal.resolver contains:

        ? SchemaResolverAdapter

        Changes to existing classes for the Framework:

        The URI resolver is used to resolve document URLs in the following places in a target WSDL 2 document:

        1) <wsdl:description> Physical document URLs in "xsi:schemaLocation" attribute value.
        2) <wsdl:import> and <wsdl:include> "location" attribute values;
        3) <xsd:schema> : <xsd:import> and <xsd:include> "schemaLocation" attribute values.

        Writing a new resolver:

        Write a class that implements org.apache.woden.resolver.URIResolver.
        The method java.net.URI resolveURI(java.net.URI uri) should return a resolved URI based on the argument uri, or null if no mapping supplied for uri.

        Specifying default resolver (org.apache.woden.resolver.default="class spec")

        The default URI resolver is initially set to the SimpleURIResolver. This means that this resolver will be used if not overridden programmatically. However it is possible to change the default resolver to some other, via the .apache.woden.resolver.default property. This can be specified either :

        (1) by the jvm command line option (-D),for example:
        -Dorg.apache.woden.resolver.default=com.myplace.mypackage.resolver.MyURIResolver
        or
        (2) as an equivalent entry in JAVAHOME\lib\wsdl.properties, for example:
        org.apache.woden.resolver.default=com.myplace.mypackage.resolver.MyURIResolver

        Associating a (non-default) URI resolver programmatically:

        Instantiate a URIResolver object and register it with the WSDLReader prior to involving WSDLReader.readWSDL(). For example:

        factory = new OMWSDLFactory(); // or DOMWSDLFactory() if desired
        WSDLReader reader = factory.newWSDLReader();
        reader.setFeature(WSDLReader.FEATURE_VALIDATION, true);
        reader.setURIResolver(new MyURIResolver()); // the one additional line of code needed.

        Configuring the Simple Resolver (specifying the simple resolver mappings file)
        This can be specified in the same ways as for the default URI Resolver as described above, namely:

        (1) by the jvm command line option (-D),for example:
        -Dorg.apache.woden.resolver.simpleresolver.catalog=c:\simpleresolver.catalog
        or
        (2) as an equivalent entry in JAVAHOME\lib\wsdl.properties, for example:
        org.apache.woden.resolver.simpleresolver.catalog=c:\simpleresolver.catalog

        Where the right hand side is the physcial location of the catalog file to be used my SimpleURIResolver .

        Contents of the Simple Resolver mapping file
        This is a text file comprising of a one line entry for each document URL found in the target WSDLs that requires mapping to a different physical location that that stated in the document. The actual location is also a URL and may be on the local filesystem or over the net.

        ......

        {talk about escape sequences and example lines, and the local-xsd set}

        Running the supplied SimpleURIResolver test

        Setup:

        1) download the simpleresolver.catalog to your local machine
        2) download the sample wsdl files (and schema) to a local directory
        3) edit the local file names in simpleresolver.catalog to point to the downloaded files
        4) compile and run the test.

        Running:

        Arg0 - the source wsdl
        Arg1 (optional) - OM | DOM - selects the corresponding parser to use in the test. Default is Woden default parser (currently DOM).

        The easiest way is to point to your simpleresolver.catalog from the command line (or IDE equivalent), something like:

        > java -Dorg.apache.woden.resolver.simpleresolver.catalog=c:\simpleresolver.catalog wsdl20test.Woden14SimpleResolverTest c:\woden-14test\woden14.wsdl OM

        Show
        Graham Turrell added a comment - Here is detail on the patch - and at the end how to run the sample: This patch includes a framework for allowing resolution of any URI found in the source document(s). The framework allows for any conformant URI resolver implementation (ie implement the URIResolver interface) to be "plugged-in" at runtime. A simple default resolver implementation is provided (SimpleURIResolver). The framework has been incorporated into both the DOM and the OM parsers. Packages: Two new packages - org.apache.woden.resolver (API : framework classes, interfaces and concrete implementations) and org.apache.woden.internal.resolver (resolver helper classes). org.apache.woden.resolver contains: ? URIResolver interface ? SimpleURIResolver ? XMLCatalogURIResolver org.apache.woden.internal.resolver contains: ? SchemaResolverAdapter Changes to existing classes for the Framework: The URI resolver is used to resolve document URLs in the following places in a target WSDL 2 document: 1) <wsdl:description> Physical document URLs in "xsi:schemaLocation" attribute value. 2) <wsdl:import> and <wsdl:include> "location" attribute values; 3) <xsd:schema> : <xsd:import> and <xsd:include> "schemaLocation" attribute values. Writing a new resolver: Write a class that implements org.apache.woden.resolver.URIResolver. The method java.net.URI resolveURI(java.net.URI uri) should return a resolved URI based on the argument uri, or null if no mapping supplied for uri. Specifying default resolver (org.apache.woden.resolver.default="class spec") The default URI resolver is initially set to the SimpleURIResolver. This means that this resolver will be used if not overridden programmatically. However it is possible to change the default resolver to some other, via the .apache.woden.resolver.default property. This can be specified either : (1) by the jvm command line option (-D),for example: -Dorg.apache.woden.resolver.default=com.myplace.mypackage.resolver.MyURIResolver or (2) as an equivalent entry in JAVAHOME\lib\wsdl.properties, for example: org.apache.woden.resolver.default=com.myplace.mypackage.resolver.MyURIResolver Associating a (non-default) URI resolver programmatically: Instantiate a URIResolver object and register it with the WSDLReader prior to involving WSDLReader.readWSDL(). For example: factory = new OMWSDLFactory(); // or DOMWSDLFactory() if desired WSDLReader reader = factory.newWSDLReader(); reader.setFeature(WSDLReader.FEATURE_VALIDATION, true); reader.setURIResolver(new MyURIResolver()); // the one additional line of code needed. Configuring the Simple Resolver (specifying the simple resolver mappings file) This can be specified in the same ways as for the default URI Resolver as described above, namely: (1) by the jvm command line option (-D),for example: -Dorg.apache.woden.resolver.simpleresolver.catalog=c:\simpleresolver.catalog or (2) as an equivalent entry in JAVAHOME\lib\wsdl.properties, for example: org.apache.woden.resolver.simpleresolver.catalog=c:\simpleresolver.catalog Where the right hand side is the physcial location of the catalog file to be used my SimpleURIResolver . Contents of the Simple Resolver mapping file This is a text file comprising of a one line entry for each document URL found in the target WSDLs that requires mapping to a different physical location that that stated in the document. The actual location is also a URL and may be on the local filesystem or over the net. ...... {talk about escape sequences and example lines, and the local-xsd set} Running the supplied SimpleURIResolver test Setup: 1) download the simpleresolver.catalog to your local machine 2) download the sample wsdl files (and schema) to a local directory 3) edit the local file names in simpleresolver.catalog to point to the downloaded files 4) compile and run the test. Running: Arg0 - the source wsdl Arg1 (optional) - OM | DOM - selects the corresponding parser to use in the test. Default is Woden default parser (currently DOM). The easiest way is to point to your simpleresolver.catalog from the command line (or IDE equivalent), something like: > java -Dorg.apache.woden.resolver.simpleresolver.catalog=c:\simpleresolver.catalog wsdl20test.Woden14SimpleResolverTest c:\woden-14test\woden14.wsdl OM
        Hide
        Graham Turrell added a comment -

        Heres a simple test to demo the patch.
        XML schema files not yet attached (pending agreement)

        Show
        Graham Turrell added a comment - Heres a simple test to demo the patch. XML schema files not yet attached (pending agreement)
        Hide
        Jeremy Hughes added a comment -

        Hi Graham, thanks for posting the above and the further patch.

        Above you describe these classes

        org.apache.woden.resolver contains:

        ? URIResolver interface
        ? SimpleURIResolver
        ? XMLCatalogURIResolver

        org.apache.woden.internal.resolver contains:

        ? SchemaResolverAdapter

        but the patch contains only these new classes:

        org.apache.woden.resolver.URIResolver
        org.apache.woden.internal.resolver.SchemaResolverAdapter
        org.apache.woden.internal.resolver.SimpleURIResolver

        The package of SimpleURIResolver is different and XMLCatalogURIResvoler is missing. The sample imports org.apache.woden.internal.resolver.SimpleURIResolver. Which should it be?

        I'm interested in the XMLCatalogURIResolver - will that read in catalog files that conform to the XML catalog standard?

        Thx.

        Show
        Jeremy Hughes added a comment - Hi Graham, thanks for posting the above and the further patch. Above you describe these classes org.apache.woden.resolver contains: ? URIResolver interface ? SimpleURIResolver ? XMLCatalogURIResolver org.apache.woden.internal.resolver contains: ? SchemaResolverAdapter but the patch contains only these new classes: org.apache.woden.resolver.URIResolver org.apache.woden.internal.resolver.SchemaResolverAdapter org.apache.woden.internal.resolver.SimpleURIResolver The package of SimpleURIResolver is different and XMLCatalogURIResvoler is missing. The sample imports org.apache.woden.internal.resolver.SimpleURIResolver. Which should it be? I'm interested in the XMLCatalogURIResolver - will that read in catalog files that conform to the XML catalog standard? Thx.
        Hide
        Graham Turrell added a comment -

        Mea Culpa - my apologies for the confusion - due to some final rejigging of the packages etc. The sourec in the zip file is correct, the text description has the errors.

        The correct package descriptions are :

        org.apache.woden.resolver contains:

        . URIResolver interface

        org.apache.woden.internal.resolver contains:

        • SchemaResolverAdapter
        • SimpleURIResolver

        XMLCatalogURIResolver will be the subject of a subsequent patch. It is an alternative to SimpleURIResolver and will indeed support OASIS XML Catalog format (in fact, the URI Resolution subset). Sorry to make you have to wait for that ..

        Show
        Graham Turrell added a comment - Mea Culpa - my apologies for the confusion - due to some final rejigging of the packages etc. The sourec in the zip file is correct, the text description has the errors. The correct package descriptions are : org.apache.woden.resolver contains: . URIResolver interface org.apache.woden.internal.resolver contains: SchemaResolverAdapter SimpleURIResolver XMLCatalogURIResolver will be the subject of a subsequent patch. It is an alternative to SimpleURIResolver and will indeed support OASIS XML Catalog format (in fact, the URI Resolution subset). Sorry to make you have to wait for that ..
        Hide
        Arthur Ryman added a comment -

        Graham, Please include the WSDL 2.0 schemas as listed at:

        http://dev.w3.org/cvsweb/2002/ws/desc/test-suite/xmlcatalog/wsdl/

        Also, please log the traffic so we can see what is getting requested and what is being retrieved from the Internet. This will let us add other resources so we can work offline.

        Show
        Arthur Ryman added a comment - Graham, Please include the WSDL 2.0 schemas as listed at: http://dev.w3.org/cvsweb/2002/ws/desc/test-suite/xmlcatalog/wsdl/ Also, please log the traffic so we can see what is getting requested and what is being retrieved from the Internet. This will let us add other resources so we can work offline.
        Hide
        Lawrence Mandel added a comment -

        Following up on Arthur's last comment, please make logging disabled by default. I think we should only enable logging for testing to avoid any potential confusion for our clients due to unexpected behaviour.

        Show
        Lawrence Mandel added a comment - Following up on Arthur's last comment, please make logging disabled by default. I think we should only enable logging for testing to avoid any potential confusion for our clients due to unexpected behaviour.
        Hide
        Arthur Ryman added a comment -

        Yes, logging must be controlled by a property file or other mechanism. The default is silence.

        BTW, what is our logging strategy?

        Show
        Arthur Ryman added a comment - Yes, logging must be controlled by a property file or other mechanism. The default is silence. BTW, what is our logging strategy?
        Hide
        Lawrence Mandel added a comment -

        I'm not sure that we have a logging strategy. Let's talk about this on next week's status call.

        Show
        Lawrence Mandel added a comment - I'm not sure that we have a logging strategy. Let's talk about this on next week's status call.
        Hide
        Graham Turrell added a comment -

        The latest source patch file for woden-14, based on current trunk.
        Junit tests to follow...

        Show
        Graham Turrell added a comment - The latest source patch file for woden-14, based on current trunk. Junit tests to follow...
        Hide
        Graham Turrell added a comment -

        Attached is a working set of JUnit tests for SimpleURIResolver. There is a simgle test for each of the 4 "hot spots" for URI resolution : wsdl2:import, wsdl2:include, xsd:import and xsd:include.
        As part of the setup, we simulate offline working by setting http.proxyHost to a nonesense URL. This guarantees that all referenced wsdl & schema are accessed locally (from a resources package included in the patch).

        To avoid the catalog entries referring to absolute paths, a new SimpleURIResolver ctor has been added to accept a single String argument representing a base location directory path, and all target entries in the catalog are considered relative to that base. This is made use of in the testcases.

        These testcases should be used in conjunction only with "woden-14-patch3.txt", the source patch, which replaces the earlier patches 1 & 2 attached to this jira.

        Show
        Graham Turrell added a comment - Attached is a working set of JUnit tests for SimpleURIResolver. There is a simgle test for each of the 4 "hot spots" for URI resolution : wsdl2:import, wsdl2:include, xsd:import and xsd:include. As part of the setup, we simulate offline working by setting http.proxyHost to a nonesense URL. This guarantees that all referenced wsdl & schema are accessed locally (from a resources package included in the patch). To avoid the catalog entries referring to absolute paths, a new SimpleURIResolver ctor has been added to accept a single String argument representing a base location directory path, and all target entries in the catalog are considered relative to that base. This is made use of in the testcases. These testcases should be used in conjunction only with "woden-14-patch3.txt", the source patch, which replaces the earlier patches 1 & 2 attached to this jira.
        Hide
        Graham Turrell added a comment -

        The latest patch for SimpleURIResolver and resolver framework. This patch replaces patches 1 & 2 and is based on current state of svn trunk.

        Show
        Graham Turrell added a comment - The latest patch for SimpleURIResolver and resolver framework. This patch replaces patches 1 & 2 and is based on current state of svn trunk.
        Hide
        Graham Turrell added a comment -

        OK - this patch has same effective content as patch 3 & the Test patch combined. I've (hopefully) sorted out the inconsistancies due to an out-of-date eclipse project I have also removed absolute path info so the patch can be applied directly to a trunk/java image.

        BTW: the new tests are found under test/org.apache.woden.resolver.

        Show
        Graham Turrell added a comment - OK - this patch has same effective content as patch 3 & the Test patch combined. I've (hopefully) sorted out the inconsistancies due to an out-of-date eclipse project I have also removed absolute path info so the patch can be applied directly to a trunk/java image. BTW: the new tests are found under test/org.apache.woden.resolver.
        Hide
        Graham Turrell added a comment -

        Some improvements to the SimpleURIResolver test cases (Handling of URLs of paths containing whitespace). Committers, please check and commit?

        Show
        Graham Turrell added a comment - Some improvements to the SimpleURIResolver test cases (Handling of URLs of paths containing whitespace). Committers, please check and commit?
        Hide
        Graham Turrell added a comment -

        SimpleURIResolverTest class only patch .

        Show
        Graham Turrell added a comment - SimpleURIResolverTest class only patch .
        Hide
        John Kaputin added a comment -

        I have applied patch files woden14fileURLpath.txt and woden14SimpleURIResolverTest.txt.

        Show
        John Kaputin added a comment - I have applied patch files woden14fileURLpath.txt and woden14SimpleURIResolverTest.txt.
        Hide
        Jeremy Hughes added a comment -

        Hi ... looks like all the patches have been applied now. Is there anything left to do on this? If not can we mark as resolved?

        Show
        Jeremy Hughes added a comment - Hi ... looks like all the patches have been applied now. Is there anything left to do on this? If not can we mark as resolved?
        Hide
        Graham Turrell added a comment -

        Hi ... I have one further patch to the simple resolver to allow the complete woden test suite to run in network isolation.

        In order to run offline, I have taken local snapshot copies of the W3C test wsdl/schema
        and created a catalog file to reference those files locally. Given that it seems we are now OK to include these files legally in Woden, we could make them part of the test suite - either by hard-wiring them into svn or creating an ant-task to go get them. What are your thoughts?

        Either way, I propose to submit a patch for only the src changes: this concludes the implementation of a URI Resolver so I suggest that at that point we may close Woden-14. Due to the (potentially) non-trivial nature of the changes for the offline testing, I propose to open another jira for the test issue. Unless there are any objections I will create that src patch and attach it here for submission.

        I also propose to open another jira to cover the OASIS resolver integration (which has not been included here).

        Finally, there is the request for logging of (candidate) resolved URI's. Given that there is not yet a logging framework in Woden, I suggest this is a further jira and that resolver logging would be added as a part of this. Again, let me know what you think.

        Show
        Graham Turrell added a comment - Hi ... I have one further patch to the simple resolver to allow the complete woden test suite to run in network isolation. In order to run offline, I have taken local snapshot copies of the W3C test wsdl/schema and created a catalog file to reference those files locally. Given that it seems we are now OK to include these files legally in Woden, we could make them part of the test suite - either by hard-wiring them into svn or creating an ant-task to go get them. What are your thoughts? Either way, I propose to submit a patch for only the src changes: this concludes the implementation of a URI Resolver so I suggest that at that point we may close Woden-14. Due to the (potentially) non-trivial nature of the changes for the offline testing, I propose to open another jira for the test issue. Unless there are any objections I will create that src patch and attach it here for submission. I also propose to open another jira to cover the OASIS resolver integration (which has not been included here). Finally, there is the request for logging of (candidate) resolved URI's. Given that there is not yet a logging framework in Woden, I suggest this is a further jira and that resolver logging would be added as a part of this. Again, let me know what you think.
        Hide
        Jeremy Hughes added a comment -

        Hi Graham, you say you "have one further patch to the simple resolver" ... I couldn't see any additional patches .. please attach when you're ready.

        I think the test code should use the local snapshot copies if they're there. If they're not then download them on-the-fly from W3C CVS (as is the case today).

        Please do go ahead and open whatever JIRAs you feel appropriate ... the "just do it then ask questions later" approach works for JIRAs

        Show
        Jeremy Hughes added a comment - Hi Graham, you say you "have one further patch to the simple resolver" ... I couldn't see any additional patches .. please attach when you're ready. I think the test code should use the local snapshot copies if they're there. If they're not then download them on-the-fly from W3C CVS (as is the case today). Please do go ahead and open whatever JIRAs you feel appropriate ... the "just do it then ask questions later" approach works for JIRAs
        Hide
        Graham Turrell added a comment -

        Hi, here is the promised patch for the source updates in readiness for
        the aforementioned "offline test" (ie all existing tests run in network isolation). It also includes a couple of minor bug fixes! Could a kindly committer (Jeremy?) please look it over, and if happy, commit ?
        Thx, Graham.

        Show
        Graham Turrell added a comment - Hi, here is the promised patch for the source updates in readiness for the aforementioned "offline test" (ie all existing tests run in network isolation). It also includes a couple of minor bug fixes! Could a kindly committer (Jeremy?) please look it over, and if happy, commit ? Thx, Graham.
        Hide
        Graham Turrell added a comment -

        As John Kaputin has committed the latest patch described above, I believe this JIRA can now be closed. Open JIRAs exist for follow-ons such as OASIS catalog, offline working etc.

        Show
        Graham Turrell added a comment - As John Kaputin has committed the latest patch described above, I believe this JIRA can now be closed. Open JIRAs exist for follow-ons such as OASIS catalog, offline working etc.
        Hide
        John Kaputin added a comment -

        This JIRA has been resolved by Graham's contributions, but not new JIRAs exist for follow-on work (e.g. Oasis catalog and WODEN-85 for caching common Schemas and DTDs used by XML Catalog)

        Show
        John Kaputin added a comment - This JIRA has been resolved by Graham's contributions, but not new JIRAs exist for follow-on work (e.g. Oasis catalog and WODEN-85 for caching common Schemas and DTDs used by XML Catalog)
        Hide
        Lawrence Mandel added a comment -

        Graham - Thanks for the great work with the feature!
        John, Jeremy - Thanks for helping Graham get his work into Woden.

        Show
        Lawrence Mandel added a comment - Graham - Thanks for the great work with the feature! John, Jeremy - Thanks for helping Graham get his work into Woden.
        Hide
        Arthur Ryman added a comment -

        Closing since the resolver is done. We still need to package the schemas in a jar.

        Show
        Arthur Ryman added a comment - Closing since the resolver is done. We still need to package the schemas in a jar.
        Hide
        Lauri Carlson added a comment -

        Dear Woden,

        running axis2 version 1.5.4 WSDLJava on w3c sparql protocol
        protocol-query wsdl, I get the following errors from woden:

        java org.apache.axis2.wsdl.WSDL2Java -uri protocol-query.wsdl -p
        my.service -wv 2 -d jaxbri -ss -sd -ssi -o /my/dir

        Woden[Error],0:0,WSDL521,Could not parse an inline schema in the WSDL at
        URL
        "jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException:
        JAR entry
        jar:file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/xml.xsd
        not found in
        /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar
        Woden[Error],0:0,WSDL521,Could not parse an inline schema in the WSDL at
        URL
        "jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException:
        JAR entry
        jar:file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/result.xsd
        not found in
        /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar

        To me resembles the bug one discussed in
        http://marc.info/?l=woden-dev&m=119929918928610&w=2,
        this time caused by references to xsd imports two level deep in the
        sparql protocol wsdl.

        Greetings

        Lauri Carlson
        lauri.carlson@helsinki.fi

        Show
        Lauri Carlson added a comment - Dear Woden, running axis2 version 1.5.4 WSDLJava on w3c sparql protocol protocol-query wsdl, I get the following errors from woden: java org.apache.axis2.wsdl.WSDL2Java -uri protocol-query.wsdl -p my.service -wv 2 -d jaxbri -ss -sd -ssi -o /my/dir Woden [Error] ,0:0,WSDL521,Could not parse an inline schema in the WSDL at URL "jar: file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl ".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException: JAR entry jar: file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/xml.xsd not found in /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar Woden [Error] ,0:0,WSDL521,Could not parse an inline schema in the WSDL at URL "jar: file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl ".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException: JAR entry jar: file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/result.xsd not found in /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar To me resembles the bug one discussed in http://marc.info/?l=woden-dev&m=119929918928610&w=2 , this time caused by references to xsd imports two level deep in the sparql protocol wsdl. Greetings Lauri Carlson lauri.carlson@helsinki.fi
        Hide
        Lauri Carlson added a comment -

        Dear list,

        running axis2 version 1.5.4 WSDLJava on w3c sparql protocol wsdl 2.0, I
        get the following errors from woden:

        java org.apache.axis2.wsdl.WSDL2Java -uri protocol-query.wsdl -p
        my.service -wv 2 -d jaxbri -ss -sd -ssi -o /my/dir

        Woden[Error],0:0,WSDL521,Could not parse an inline schema in the WSDL at
        URL
        "jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException:
        JAR entry
        jar:file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/xml.xsd
        not found in
        /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar
        Woden[Error],0:0,WSDL521,Could not parse an inline schema in the WSDL at
        URL
        "jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException:
        JAR entry
        jar:file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/result.xsd
        not found in
        /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar

        To me this looks like another woden resolver bug, like the one discussed in
        http://marc.info/?l=woden-dev&m=119929918928610&w=2,
        this time caused by references to xsd imports two level deep in the
        sparql protocol wsdl.

        Greetings

        Lauri Carlson
        lauri.carlson@helsinki.fi

        Show
        Lauri Carlson added a comment - Dear list, running axis2 version 1.5.4 WSDLJava on w3c sparql protocol wsdl 2.0, I get the following errors from woden: java org.apache.axis2.wsdl.WSDL2Java -uri protocol-query.wsdl -p my.service -wv 2 -d jaxbri -ss -sd -ssi -o /my/dir Woden [Error] ,0:0,WSDL521,Could not parse an inline schema in the WSDL at URL "jar: file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl ".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException: JAR entry jar: file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/xml.xsd not found in /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar Woden [Error] ,0:0,WSDL521,Could not parse an inline schema in the WSDL at URL "jar: file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/SparqlService.wsdl ".,java.lang.RuntimeException:org.apache.ws.commons.schema.XmlSchemaException: JAR entry jar: file:///usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/jar:file://file:/usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar!/META-INF/result.xsd not found in /usr/share/tomcat/webapps/axis2/WEB-INF/services/SparqlService.aar To me this looks like another woden resolver bug, like the one discussed in http://marc.info/?l=woden-dev&m=119929918928610&w=2 , this time caused by references to xsd imports two level deep in the sparql protocol wsdl. Greetings Lauri Carlson lauri.carlson@helsinki.fi
        Hide
        Sagara Gunathunga added a comment -

        Hi Lauri ,

        Can you elaborate more on this issue ?

        I'm little confusing how you get AAR related error trace with WSDL2Java tool ?

        Great if you can provide the exact steps you followed and your sample program in order to reproduce this issue.

        Thanks !

        Show
        Sagara Gunathunga added a comment - Hi Lauri , Can you elaborate more on this issue ? I'm little confusing how you get AAR related error trace with WSDL2Java tool ? Great if you can provide the exact steps you followed and your sample program in order to reproduce this issue. Thanks !

          People

          • Assignee:
            Sagara Gunathunga
            Reporter:
            Arthur Ryman
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development