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 R <ra...@gmail.com> on 2009/03/18 17:48:56 UTC
[DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Section 1.10.5 of the OSOA and Section 12.5 of the OASIS Assembly Spec for
this topic is shown below....
"For certain types of artifact, there are existing and commonly used
mechanisms for referencing a specific concrete location where the artifact
can be resolved.
Examples of these mechanisms include:
• For WSDL files, the @wsdlLocation attribute is a hint that has a URI value
pointing to the place holding the WSDL itself.
• For XSDs, the @schemaLocation attribute is a hint which matches the
namespace to a URI where the XSD is found.
Note: In neither of these cases is the runtime obliged to use the location
hint and the URI does not have to be dereferenced.
SCA permits the use of these mechanisms. Where present, these mechanisms
take precendence over the SCA mechanisms. However, use of these mechanisms
is discouraged because tying assemblies to addresses in this way makes the
assemblies less flexible and prone to errors when changes are made to the
overall SCA Domain.
Note: If one of these mechanisms is present, but there is a failure to find
the resource indicated when using the mechanism (eg the URI is incorrect or
invalid, say) the SCA runtime MUST raise an error and MUST NOT attempt to
use SCA resolution mechanisms as an alternative."
Looks like currently Tuscany runtime always uses the SCA resolution
mechanism to resolve the @wsdlLocation of WSDL and @schemaLocation of XSD's
files, instead of using the
non-SCA mechanism as suggested by specs. This issue is raised as
TUSCANY-2906.
But my confusion is that, the specs also says that the usage of non-SCA
resolution mechanisms is discouraged.
Like to take suggestions from the community, as what needs to be supported.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Scott Kurz <sc...@gmail.com>.
+1 and thank you for summarizing Simon.
Scott
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by ant elder <an...@gmail.com>.
I think TUSCANY-2946 is a seperate issue, and it may be intermittent
or only in some environments. I've added that testcase back into the
build, does anyone else get a test fail when it runs now?
...ant
On Wed, Apr 1, 2009 at 1:35 AM, Raymond Feng <en...@gmail.com> wrote:
> It seems TUSCANY-2943, 2944, 2945, 2946, 2947 are related to this
> regression. Please go ahead to revert it and remove the @Ignores for the
> failing test cases.
>
> Thanks,
> Raymond
> From: Ramkumar R
> Sent: Tuesday, March 31, 2009 3:09 AM
> To: dev@tuscany.apache.org
> Subject: Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
> Artifacts
> The fix to TUSCANY-2906, has created problems in resolving the in-line
> schema as mentioned in
> TUSCANY-2947 and TUSCANY-2948.
>
> I see that XSDModelResolver, is basically used to resolve the in-line schema
> (which does not have any
> schemalocation attribute). So we need not follow the process as we do for
> WSDLModelResolver.
>
> In case of XSD resolver, the @schemaLocation is handled by
> org.apache.ws.commons.schema.XmlSchemaCollection
> for any path specified in the schemaLocation attribute relative to the
> current contribution.
>
> In case, if we need to handle non-relative path (i.e., absolute paths) as
> locations (which is not the requirement
> as this point of time), then we need a change here.
>
> So I will revert some of the changes made in XSDModelResolver to fix
> TUSCANY-2947 and TUSCANY-2948.
>
> On Thu, Mar 26, 2009 at 3:42 PM, Ramkumar R <ra...@gmail.com> wrote:
>>
>> Apologize for a late response, just got busy with other fixes in spring
>> implementation module.
>>
>> Thanks Simon for the clarification, I think I got little confused with the
>> URL resolution in WSDLLocater and
>> the artifact model resolution.
>>
>> I made the necessary changes as discussed (as per the process mentioned in
>> Simon note) in my local
>> code and identified some disadvantages as shown below.
>>
>> 1. As Simon also mentioned, step 2 in the process will never fail, we will
>> end up using the non-sca mechanism
>> for most of the cases.
>>
>> 2. Using non-sca mechanism as a preferred first approach to resolve
>> imports, makes the resolution to happen
>> multiple times if the same imported artifact is used multiple times. (No
>> issues seen so far because of this).
>>
>> 3. Once the artifact is resolved (identified by system path) using non-sca
>> mechanism, the resolved artifact is just
>> an definition created using the system path, which might not have other
>> information like the @location OR @schemaLocation
>> value as artifact URI, which is required by WSDLServiceGenerator at the
>> later stage. (I have fixed this issue by setting the
>> artifact URI same as the system path to the artifact to give a go for
>> WSDLServiceGenerator, not sure if there could
>> be other implications).
>>
>> Let me check in the code I have, so that we can evaluate the scenario
>> better.
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Ramkumar R <ra...@gmail.com>.
On Thu, Apr 23, 2009 at 3:19 AM, Raymond Feng <en...@gmail.com> wrote:
> The latest OASIS SCA Assembly Spec has the following:
>
> 3509 When a contribution contains a reference to an artifact from a
> namespace that is declared in an import
> 3510 statement of the contribution, if the SCA artifact resolution
> mechanism is used to resolve the artifact, the
> 3511 SCA runtime MUST resolve artifacts in the following order:
> 3512 1. from the locations identified by the import statement(s) for the
> namespace. Locations MUST NOT
> 3513 be searched recursively in order to locate artifacts (i.e. only a
> one-level search is performed).
> 3514 2. from the contents of the contribution itself. [ASM12023]
>
> So it should be import first and local second. This is also the order that
> OSGi uses to resolve the classes.
>
>
Interesting.... I believe, this is not going to affect the code in 1.x and
we will be planning to adopt this approach in 2.x.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving Artifacts
Posted by Raymond Feng <en...@gmail.com>.
The latest OASIS SCA Assembly Spec has the following:
3509 When a contribution contains a reference to an artifact from a
namespace that is declared in an import
3510 statement of the contribution, if the SCA artifact resolution mechanism
is used to resolve the artifact, the
3511 SCA runtime MUST resolve artifacts in the following order:
3512 1. from the locations identified by the import statement(s) for the
namespace. Locations MUST NOT
3513 be searched recursively in order to locate artifacts (i.e. only a
one-level search is performed).
3514 2. from the contents of the contribution itself. [ASM12023]
So it should be import first and local second. This is also the order that
OSGi uses to resolve the classes.
--------------------------------------------------
From: "Scott Kurz" <sc...@gmail.com>
Sent: Wednesday, April 22, 2009 12:14 PM
To: <de...@tuscany.apache.org>
Subject: Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
> Ram,
>
> Thanks for the updated summary.
>
> I have a couple of questions, if you don't mind.
>
> First, this is probably an obvious question, but by the "SCA
> resolution mechanism" you mean:
> 1. first look in the current contribution
> and if not found
> 2. then look for SCA contribution import/exports.
>
> Second, the behavior you described makes sense to me, but we do agree
> it is not what the Assembly spec says, right? I am not trying to
> push on spec compliance at the moment, just getting clear since we'd
> been discussing the spec statement in the past.
>
> Thanks, Scott
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Ramkumar R <ra...@gmail.com>.
On Thu, Apr 23, 2009 at 12:44 AM, Scott Kurz <sc...@gmail.com> wrote:
> Ram,
>
> Thanks for the updated summary.
>
> I have a couple of questions, if you don't mind.
>
> First, this is probably an obvious question, but by the "SCA
> resolution mechanism" you mean:
> 1. first look in the current contribution
> and if not found
> 2. then look for SCA contribution import/exports.
Yes you are right, this is the approach we are currently using by saying
as "SCA resolution mechnanism".
>
> Second, the behavior you described makes sense to me, but we do agree
> it is not what the Assembly spec says, right? I am not trying to
> push on spec compliance at the moment, just getting clear since we'd
> been discussing the spec statement in the past.
>
> Thanks, Scott
>
Yeah, we might be slightly deviating from what specs says in this case. I
believe we
are still compliant with specs in terms of resolving XSD imports with
@schemaLocation.
But the case is little different in case of resoling WSDL imports. We might
need to take this
up with the specs teams to reconsider for this case.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Scott Kurz <sc...@gmail.com>.
Ram,
Thanks for the updated summary.
I have a couple of questions, if you don't mind.
First, this is probably an obvious question, but by the "SCA
resolution mechanism" you mean:
1. first look in the current contribution
and if not found
2. then look for SCA contribution import/exports.
Second, the behavior you described makes sense to me, but we do agree
it is not what the Assembly spec says, right? I am not trying to
push on spec compliance at the moment, just getting clear since we'd
been discussing the spec statement in the past.
Thanks, Scott
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Ramkumar R <ra...@gmail.com>.
I would like to just summarize, the current functionality used to resolve
WSDL and XSD's using
WSDLResolver and XSDResolver and see how we want to handle the situation
further.
In case of WSDL we have two approaches that are currently used....
a) For the WSDL that's been specified in the SCDL file we use the SCA
resolution mechanism always.
b) For the WSDL imports using @wsdlLocation attribute, we now use the
non-SCA mechanism as
the first preferred approach to identify the artifacts, if the artifact is
not found using the non-SCA mechanism then
we try to use the SCA mechanism to resolve the artifacts.
Similarly, in case of XSD we have two approaches again....
a) For inline XSD's we use the SCA resolution mechanism always.
b) For XSD imports using @schemaLocation attribute, we use the non-SCA
mechanism as the preferred
first approach and use the SCA mechanism if its not resolved with the
non-SCA mechanism.
The reason, why I had to revert some changes in XSDResolver is for the
reason that I had accidentally made the inline schemas
to follow the norms of using non-SCA mechanism as first approach, which is
invalid and had to revert the code and keep these norms only
for XSD imports.
The XSDResolver allows us to specify absolutePath's and URL's in the
@schemaLocation attribute and resolves them accordingly.
But same is not the case with WSDL @wsdlLocation attribute, were only
relativePaths are allowed to resolve even with the
non-SCA mechanism.
My question here is that, are we also expecting the WSDL @wsdlLocation
attribute to support absolutePath's.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Ramkumar R <ra...@gmail.com>.
Looks like TUSCANY-2944 is also a separate issue and its been already fixed
by Luciano.
TUSCANY-2945, 2947 and 2948 is now fixed (part of this regression).
TUSCANY-2943 looks like a separate issue for me, as I noticed a
TransformationException from the databinding module.
On Wed, Apr 1, 2009 at 6:05 AM, Raymond Feng <en...@gmail.com> wrote:
> It seems TUSCANY-2943, 2944, 2945, 2946, 2947 are related to this
> regression. Please go ahead to revert it and remove the @Ignores for the
> failing test cases.
>
> Thanks,
> Raymond
> *From:* Ramkumar R <ra...@gmail.com>
> *Sent:* Tuesday, March 31, 2009 3:09 AM
> *To:* dev@tuscany.apache.org
> *Subject:* Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for
> Resolving Artifacts
>
> The fix to TUSCANY-2906, has created problems in resolving the in-line
> schema as mentioned in
> TUSCANY-2947 and TUSCANY-2948.
>
> I see that XSDModelResolver, is basically used to resolve the in-line
> schema (which does not have any
> schemalocation attribute). So we need not follow the process as we do for
> WSDLModelResolver.
>
> In case of XSD resolver, the @schemaLocation is handled by
> org.apache.ws.commons.schema.XmlSchemaCollection
> for any path specified in the schemaLocation attribute relative to the
> current contribution.
>
> In case, if we need to handle non-relative path (i.e., absolute paths) as
> locations (which is not the requirement
> as this point of time), then we need a change here.
>
> So I will revert some of the changes made in XSDModelResolver to fix
> TUSCANY-2947 and TUSCANY-2948.
>
> On Thu, Mar 26, 2009 at 3:42 PM, Ramkumar R <ra...@gmail.com> wrote:
>
>> Apologize for a late response, just got busy with other fixes in spring
>> implementation module.
>>
>> Thanks Simon for the clarification, I think I got little confused with the
>> URL resolution in WSDLLocater and
>> the artifact model resolution.
>>
>> I made the necessary changes as discussed (as per the process mentioned in
>> Simon note) in my local
>> code and identified some disadvantages as shown below.
>>
>> 1. As Simon also mentioned, step 2 in the process will never fail, we will
>> end up using the non-sca mechanism
>> for most of the cases.
>>
>> 2. Using non-sca mechanism as a preferred first approach to resolve
>> imports, makes the resolution to happen
>> multiple times if the same imported artifact is used multiple times. (No
>> issues seen so far because of this).
>>
>> 3. Once the artifact is resolved (identified by system path) using non-sca
>> mechanism, the resolved artifact is just
>> an definition created using the system path, which might not have other
>> information like the @location OR @schemaLocation
>> value as artifact URI, which is required by WSDLServiceGenerator at the
>> later stage. (I have fixed this issue by setting the
>> artifact URI same as the system path to the artifact to give a go for
>> WSDLServiceGenerator, not sure if there could
>> be other implications).
>>
>> Let me check in the code I have, so that we can evaluate the scenario
>> better.
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>>
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving Artifacts
Posted by Raymond Feng <en...@gmail.com>.
It seems TUSCANY-2943, 2944, 2945, 2946, 2947 are related to this regression. Please go ahead to revert it and remove the @Ignores for the failing test cases.
Thanks,
Raymond
From: Ramkumar R
Sent: Tuesday, March 31, 2009 3:09 AM
To: dev@tuscany.apache.org
Subject: Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving Artifacts
The fix to TUSCANY-2906, has created problems in resolving the in-line schema as mentioned in
TUSCANY-2947 and TUSCANY-2948.
I see that XSDModelResolver, is basically used to resolve the in-line schema (which does not have any
schemalocation attribute). So we need not follow the process as we do for WSDLModelResolver.
In case of XSD resolver, the @schemaLocation is handled by org.apache.ws.commons.schema.XmlSchemaCollection
for any path specified in the schemaLocation attribute relative to the current contribution.
In case, if we need to handle non-relative path (i.e., absolute paths) as locations (which is not the requirement
as this point of time), then we need a change here.
So I will revert some of the changes made in XSDModelResolver to fix TUSCANY-2947 and TUSCANY-2948.
On Thu, Mar 26, 2009 at 3:42 PM, Ramkumar R <ra...@gmail.com> wrote:
Apologize for a late response, just got busy with other fixes in spring implementation module.
Thanks Simon for the clarification, I think I got little confused with the URL resolution in WSDLLocater and
the artifact model resolution.
I made the necessary changes as discussed (as per the process mentioned in Simon note) in my local
code and identified some disadvantages as shown below.
1. As Simon also mentioned, step 2 in the process will never fail, we will end up using the non-sca mechanism
for most of the cases.
2. Using non-sca mechanism as a preferred first approach to resolve imports, makes the resolution to happen
multiple times if the same imported artifact is used multiple times. (No issues seen so far because of this).
3. Once the artifact is resolved (identified by system path) using non-sca mechanism, the resolved artifact is just
an definition created using the system path, which might not have other information like the @location OR @schemaLocation
value as artifact URI, which is required by WSDLServiceGenerator at the later stage. (I have fixed this issue by setting the
artifact URI same as the system path to the artifact to give a go for WSDLServiceGenerator, not sure if there could
be other implications).
Let me check in the code I have, so that we can evaluate the scenario better.
--
Thanks & Regards,
Ramkumar Ramalingam
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Ramkumar R <ra...@gmail.com>.
The fix to TUSCANY-2906, has created problems in resolving the in-line
schema as mentioned in
TUSCANY-2947 and TUSCANY-2948.
I see that XSDModelResolver, is basically used to resolve the in-line schema
(which does not have any
schemalocation attribute). So we need not follow the process as we do for
WSDLModelResolver.
In case of XSD resolver, the @schemaLocation is handled by
org.apache.ws.commons.schema.XmlSchemaCollection
for any path specified in the schemaLocation attribute relative to the
current contribution.
In case, if we need to handle non-relative path (i.e., absolute paths) as
locations (which is not the requirement
as this point of time), then we need a change here.
So I will revert some of the changes made in XSDModelResolver to fix
TUSCANY-2947 and TUSCANY-2948.
On Thu, Mar 26, 2009 at 3:42 PM, Ramkumar R <ra...@gmail.com> wrote:
> Apologize for a late response, just got busy with other fixes in spring
> implementation module.
>
> Thanks Simon for the clarification, I think I got little confused with the
> URL resolution in WSDLLocater and
> the artifact model resolution.
>
> I made the necessary changes as discussed (as per the process mentioned in
> Simon note) in my local
> code and identified some disadvantages as shown below.
>
> 1. As Simon also mentioned, step 2 in the process will never fail, we will
> end up using the non-sca mechanism
> for most of the cases.
>
> 2. Using non-sca mechanism as a preferred first approach to resolve
> imports, makes the resolution to happen
> multiple times if the same imported artifact is used multiple times. (No
> issues seen so far because of this).
>
> 3. Once the artifact is resolved (identified by system path) using non-sca
> mechanism, the resolved artifact is just
> an definition created using the system path, which might not have other
> information like the @location OR @schemaLocation
> value as artifact URI, which is required by WSDLServiceGenerator at the
> later stage. (I have fixed this issue by setting the
> artifact URI same as the system path to the artifact to give a go for
> WSDLServiceGenerator, not sure if there could
> be other implications).
>
> Let me check in the code I have, so that we can evaluate the scenario
> better.
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Ramkumar R <ra...@gmail.com>.
Apologize for a late response, just got busy with other fixes in spring
implementation module.
Thanks Simon for the clarification, I think I got little confused with the
URL resolution in WSDLLocater and
the artifact model resolution.
I made the necessary changes as discussed (as per the process mentioned in
Simon note) in my local
code and identified some disadvantages as shown below.
1. As Simon also mentioned, step 2 in the process will never fail, we will
end up using the non-sca mechanism
for most of the cases.
2. Using non-sca mechanism as a preferred first approach to resolve imports,
makes the resolution to happen
multiple times if the same imported artifact is used multiple times. (No
issues seen so far because of this).
3. Once the artifact is resolved (identified by system path) using non-sca
mechanism, the resolved artifact is just
an definition created using the system path, which might not have other
information like the @location OR @schemaLocation
value as artifact URI, which is required by WSDLServiceGenerator at the
later stage. (I have fixed this issue by setting the
artifact URI same as the system path to the artifact to give a go for
WSDLServiceGenerator, not sure if there could
be other implications).
Let me check in the code I have, so that we can evaluate the scenario
better.
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Simon Laws <si...@googlemail.com>.
> 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
...snip
Not sure I understand what you are saying here Ram. You seem to move
from looking in the current contribution to assuming that there is a
invalid import location. Based on the conversation on this thread I
would imagine a process such as
1. get artifact location from import/include
2. if there is a location then do artifact specific resolution
3. retrieve the artifact using the location provided
4. if no artifact found look in the current contribution for an
artifact providing the appropriate namespace
5. if not found report an error
6. else do sca specific resolution
7. use the sca artifact resolution mechanism to find an artifact
providing the appropriate namespace
8. if not found report an error
Two issues that have been discussed here
should line 4 come before line 3
- I don't think it should as having 3 firstallows the use to be
explicit if they want to be
for WSDL file it seems that line 2 will never be false.
- so how do make WSDL import subject to SCA resolution? Step
outside WS-I. Seems like an OASIS spec question.
Simon
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Ramkumar R <ra...@gmail.com>.
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 <sc...@gmail.com> wrote:
> On Wed, Mar 18, 2009 at 7:34 PM, Luciano Resende <lu...@gmail.com>
> 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 <en...@gmail.com> 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
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Scott Kurz <sc...@gmail.com>.
On Wed, Mar 18, 2009 at 7:34 PM, Luciano Resende <lu...@gmail.com> 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 <en...@gmail.com> 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
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving Artifacts
Posted by Raymond Feng <en...@gmail.com>.
IMO, if the wsdlLocation/schemaLocation fails to resolve the artifacts, we
should not try to use the SCA way.
Thanks,
Raymond
--------------------------------------------------
From: "Luciano Resende" <lu...@gmail.com>
Sent: Wednesday, March 18, 2009 4:34 PM
To: <de...@tuscany.apache.org>
Subject: Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
> On Wed, Mar 18, 2009 at 4:05 PM, Raymond Feng <en...@gmail.com> wrote:
>> Hi,
>>
>> I don't think there is a conflict in the spec. Even though the SCA
>> resolution mechanism is preferred, we have to honor the non-SCA way first
>> if
>> the users choose to use to use wsdlLocation or schemaLocation.
>>
>
> 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. And I'm just wondering
> what the side effects of using SCA resolution might be when they are
> not expected (e.g out of a sudden, wsdl and schemas from imported
> contributions start to be used).
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende
> http://lresende.blogspot.com/
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Posted by Luciano Resende <lu...@gmail.com>.
On Wed, Mar 18, 2009 at 4:05 PM, Raymond Feng <en...@gmail.com> wrote:
> Hi,
>
> I don't think there is a conflict in the spec. Even though the SCA
> resolution mechanism is preferred, we have to honor the non-SCA way first if
> the users choose to use to use wsdlLocation or schemaLocation.
>
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. And I'm just wondering
what the side effects of using SCA resolution might be when they are
not expected (e.g out of a sudden, wsdl and schemas from imported
contributions start to be used).
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving Artifacts
Posted by Raymond Feng <en...@gmail.com>.
Hi,
I don't think there is a conflict in the spec. Even though the SCA
resolution mechanism is preferred, we have to honor the non-SCA way first if
the users choose to use to use wsdlLocation or schemaLocation.
Thanks,
Raymond
From: Ramkumar R
Sent: Wednesday, March 18, 2009 9:48 AM
To: dev@tuscany.apache.org
Subject: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving
Artifacts
Section 1.10.5 of the OSOA and Section 12.5 of the OASIS Assembly Spec for
this topic is shown below....
"For certain types of artifact, there are existing and commonly used
mechanisms for referencing a specific concrete location where the artifact
can be resolved.
Examples of these mechanisms include:
• For WSDL files, the @wsdlLocation attribute is a hint that has a URI value
pointing to the place holding the WSDL itself.
• For XSDs, the @schemaLocation attribute is a hint which matches the
namespace to a URI where the XSD is found.
Note: In neither of these cases is the runtime obliged to use the location
hint and the URI does not have to be dereferenced.
SCA permits the use of these mechanisms. Where present, these mechanisms
take precendence over the SCA mechanisms. However, use of these mechanisms
is discouraged because tying assemblies to addresses in this way makes the
assemblies less flexible and prone to errors when changes are made to the
overall SCA Domain.
Note: If one of these mechanisms is present, but there is a failure to find
the resource indicated when using the mechanism (eg the URI is incorrect or
invalid, say) the SCA runtime MUST raise an error and MUST NOT attempt to
use SCA resolution mechanisms as an alternative."
Looks like currently Tuscany runtime always uses the SCA resolution
mechanism to resolve the @wsdlLocation of WSDL and @schemaLocation of XSD's
files, instead of using the
non-SCA mechanism as suggested by specs. This issue is raised as
TUSCANY-2906.
But my confusion is that, the specs also says that the usage of non-SCA
resolution mechanisms is discouraged.
Like to take suggestions from the community, as what needs to be supported.
--
Thanks & Regards,
Ramkumar Ramalingam