You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Ramkumar Ramalingam (JIRA)" <de...@tuscany.apache.org> on 2009/03/17 08:12:50 UTC
[jira] Commented: (TUSCANY-2906) WSDL/XSD imports should use
location/schemaLocation as hints and not fail due to locations that don't
map to actual locations
[ https://issues.apache.org/jira/browse/TUSCANY-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12682578#action_12682578 ]
Ramkumar Ramalingam commented on TUSCANY-2906:
----------------------------------------------
Hi Scott,
I tried the scenario you have attached and what I notice is that Tuscany throws ContributionResolveException in both the cases...
Case 1: improper @schemaLocation on XSD import
SEVERE: Error in contribution: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.ws.commons.schema.XmlSchemaException: C:\Tuscany\trunk\samples\wsdl_files\wsdl\1\2a\test.xsd (The system cannot find the path specified.)
Exception in thread "main" org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.ws.commons.schema.XmlSchemaException: C:\Tuscany\trunk\samples\wsdl_files\wsdl\1\2a\test.xsd (The system cannot find the path specified.)
at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:192)
at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANodeFromClassLoader(NodeFactoryImpl.java:37)
at bigbank.server.BigBankServer.main(BigBankServer.java:48)
Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: org.apache.ws.commons.schema.XmlSchemaException: C:\Tuscany\trunk\samples\wsdl_files\wsdl\1\2a\test.xsd (The system cannot find the path specified.)
at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:381)
at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:77)
at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:388)
at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:183)
at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:452)
at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:988)
at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:89)
at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:388)
at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:183)
at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:203)
at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:57)
at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:106)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:596)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:423)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:195)
at org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:517)
at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:188)
... 2 more
Case 2: improper @location on WSDL import
SEVERE: Error in contribution: org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.io.FileNotFoundException: C:\Tuscany\trunk\samples\simple-bigbank-spring\target\wsdl_files2\test.wsdl (The system cannot find the path specified.)
Exception in thread "main" org.osoa.sca.ServiceRuntimeException: org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.io.FileNotFoundException: C:\Tuscany\trunk\samples\simple-bigbank-spring\target\wsdl_files2\test.wsdl (The system cannot find the path specified.)
at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:192)
at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANodeFromClassLoader(NodeFactoryImpl.java:37)
at bigbank.server.BigBankServer.main(BigBankServer.java:48)
Caused by: org.apache.tuscany.sca.contribution.service.ContributionResolveException: java.io.FileNotFoundException: C:\Tuscany\trunk\samples\simple-bigbank-spring\target\wsdl_files2\test.wsdl (The system cannot find the path specified.)
at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:381)
at org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor.resolve(WebServiceBindingProcessor.java:77)
at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:388)
at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:183)
at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveContracts(BaseAssemblyProcessor.java:452)
at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:988)
at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:89)
at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:388)
at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:183)
at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:203)
at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:57)
at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:106)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:596)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:423)
at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:195)
at org.apache.tuscany.sca.node.impl.NodeImpl.configureNode(NodeImpl.java:517)
at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:188)
... 2 more
Which I think is the expected results, not sure if you are mean to point out some else out of this issue.
I like to get more details on the issue raised, as what is the expectations? Please clarify.
> WSDL/XSD imports should use location/schemaLocation as hints and not fail due to locations that don't map to actual locations
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-2906
> URL: https://issues.apache.org/jira/browse/TUSCANY-2906
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Data Binding Runtime
> Reporter: Scott Kurz
> Assignee: Ramkumar Ramalingam
> Priority: Minor
> Attachments: 2906.recreate.jar
>
>
> My test app uses wsdl import and xsd import with @location and @schemaLocation, respectively, specifying values that don't actually correspond to relative locations within my contribution JAR. (The motive might be that in moving from my test env to my deploy env i've shuffled the relative paths around for some reason).
> When reading BasicProfile 1.1, section 4.2.4, I take that to mean that our runtime should be able to handle an "incorrect" @location (though 4.2.3 says it shouldn't be empty). Instead we blow up.
> In reading the XSD spec quickly I think the same should apply to @schemaLocation on XSD import, though I don't see that BP says anything about this. I did test to confirm that if @schemaLocation is simply left blank then we have no problem finding the XSD within the contribution... it's just a problem if it's set to a value that doesn't correspond to anything in the JAR.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.