Looking at more details in the existing code... here is what happens for the
imports in WSDL's and XSD's
In both the cases (i.e., for WSDL imports and XSD imports) the SCA artifact
resolution mechanism
is used only when the import location string start with a "/" (assuming that
when the location starts with "/"
then the URL is relative to the contribution).
For XSD imports, when the location string does not start with "/", then
first we see if the files are available within
the current contribution, if found we resolve the imports else we create a
InputSource object with the invalid
import location (assuming that its just a suggestion) and return them. For
the above reason, for a invalid import location
we see a error message from the org.apache.ws.commons.schema.SchemaBuilder
as shown below.
Mar 20, 2009 11:42:19 AM
org.apache.tuscany.sca.binding.ws.xml.WebServiceBindingProcessor null
SEVERE: Error in contribution:
org.apache.tuscany.sca.contribution.service.ContributionResolveException:
org.apache.ws.commons.schema.XmlSchemaException:
C:\Tuscany\trunk\wsdl\1\2a\test.xsd (The system cannot find the path
specified.)
Caused by: org.apache.ws.commons.schema.XmlSchemaException:
C:\Tuscany\trunk\wsdl\1\2a\test.xsd (The system cannot find the path
specified.)
at
org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:351)
at
org.apache.ws.commons.schema.SchemaBuilder.resolveXmlSchema(SchemaBuilder.java:1839)
at
org.apache.ws.commons.schema.SchemaBuilder.handleImport(SchemaBuilder.java:1577)
at
org.apache.ws.commons.schema.SchemaBuilder.handleXmlSchemaElement(SchemaBuilder.java:186)
at
org.apache.ws.commons.schema.SchemaBuilder.build(SchemaBuilder.java:83)
at
org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:424)
at
org.apache.ws.commons.schema.XmlSchemaCollection.read(XmlSchemaCollection.java:418)
at
org.apache.tuscany.sca.xsd.xml.XSDModelResolver.loadOnDemand(XSDModelResolver.java:161)
For WSDL imports, in case of invalid import location we use to throw an
exception when the artifact is not found
with in the current contribution. I modified the code to create a
InputSource object and return with a invalid
import location (assuming that its just a suggestion). This way we see the
following error message...
Caused by: java.io.FileNotFoundException:
C:\Tuscany\trunk\samples\simple-bigbank-spring\target\wsdl_files2\test.wsdl
(The system cannot find the path specified.)
at java.io.FileInputStream.<init>(FileInputStream.java:125)
at java.io.FileInputStream.<init>(FileInputStream.java:85)
at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown
Source)
at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
So even if Tuscany code treats the invalid import location as suggestions,
we see error messages from other sources like SchemaBuilder and DOMParser.
Not sure if this is the expected results??
On Thu, Mar 19, 2009 at 6:36 AM, Scott Kurz <[email protected]> wrote:
> On Wed, Mar 18, 2009 at 7:34 PM, Luciano Resende <[email protected]>
> wrote:
>
> > I think the issue is, when wsdlLocation and schemaLocation is
> > provided, but it fails to properly resolve... should we fall back to
> > the SCA resolution mechanism or should we fail.
>
> We do have to deal with this issue.
>
> However, I think we first have to deal with what it means to say that,
> for example: "@schemaLocation was provided but fails to properly
> resolve".
>
> So in addition to being an SCA runtime we're also a runtime that
> supports XSD imports, and it seems we must define what the behavior of
> our non-SCA mechanism for resolving XSD imports is.
>
> In TUSCANY-2906, I'm suggesting that for our non-SCA XSD import, we at
> least look within the current contribution in the case that
> @schemaLocation is specified but incorrect/invalid. And I'd argue
> the same for WSDL import with @location. (Hadn't considered
> @wsdlLocation).
>
> On Wed, Mar 18, 2009 at 7:55 PM, Raymond Feng <[email protected]> wrote:
> > IMO, if the wsdlLocation/schemaLocation fails to resolve the artifacts,
> we
> > should not try to use the SCA way.
>
> I agree the OSOA and OASIS specs clearly state we should not use the
> SCA way (contribution import) if we cannot find the XSD or WSDL with
> our non-SCA mechanisms.
>
> The thing which bothers me is this: how is one actually supposed to
> use the SCA way (contribution import)? We do make it difficult. For
> example, I guess you have to make sure never to use xsd:import
> @schemaLocation(s). If you'd like to refactor a set of schemas into
> their own contribution, you might have to go remove existing
> @schemaLocation(s). I imagine that the spec is written the way it
> is to cut down the complexity of chained imports and competing,
> co-existing artifact resolution methods, but if there are no schema
> definitions within my contribution how else would I want to resolve
> the import than via the SCA way? What's to get confused about?
>
> And how do we handle WSDL import? It says in the Basic Profile that
> wsdl import is supposed to have a non-empty @location. So you can
> never use SCA contribution import to resolve a WSDL import?
>
> Scott
>
--
Thanks & Regards,
Ramkumar Ramalingam
