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/05/27 10:07:09 UTC
[DISCUSS] WSDL/XSD imports should use location/schemaLocation as
hints
Hi All,
We had a discuss on this topic (Use of non-SCA Mechanisms for Resolving
Artifacts) in the month of March under this thread
http://www.mail-archive.com/dev@tuscany.apache.org/msg05956.html
What we agreed on as a process to follow for the non-SCA mechanism is.....
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
So going by this process, if the artifact specified in the location
attribute is not found an error is reported either in Step 5 or 8.
I believe, TUSCANY-2906 has been re-opened with an expectation that, the
artifacts should be resolved even if the
location attribute points to an invalid location. I believe that brings back
the question which had in the past as posted here....
http://www.mail-archive.com/dev@tuscany.apache.org/msg06028.html
Now, the question is that, should we allow the artifact (WSDL/XSD) to get
resolved even if the artifact specified in the location
attribute is not found anywhere after following the above process?
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] WSDL/XSD imports should use location/schemaLocation
as hints
Posted by Mike Edwards <mi...@gmail.com>.
Simon Laws wrote:
> Hi Ram
>
> I don't think there is a good reason for them to be different. It
> seems that the OASIS spec now adds more detail to the artifact
> resolution section of the spec but I don't think this added detail
> means that the behaviour changes.
>
> We do though need to run the "step 4" question to ground. So far, in
> the context of TUSCANY-2906, it seems that the conversation has come
> down to whether step 4 in our list of steps could be considered to be
> part of the artifact specific resolution mechanism.
>
> It has been pointed out that the artifact specific and sca
> (imports/exports) mechanism should not be mixed. Sounds sensible as if
> you were going to rely on the SCA mechanism you would have included an
> import for the namespace you require.
>
> It has also been pointed out that the artifact specific mechanism is
> extremely flexible and the runtime could decide to look in the current
> contribution to find artifacts where the location hint doesn't help
>
> So on this basis do we summarize this by saying that we take step 4 at
> face value when it talks about looking in the *current* contribution
> and include it in the artifact specific resolution process?
>
> Simon
>
Folks,
I think that the idea of looking into the current contribution is the wsdlLocation (or xsdLocation)
fails is OK - ie "step 4".
That can't be regarded as "using the SCA resolution mechanism" since that would imply looking at the
imports and at the contributions exporting those namespaces (etc).
Just looking at the local contribution seems ok as a part of "the artifact specific resolution
mechanism". Of course, this begs the question of why you would ever bother with wsdlLocation if you
have a local copy of the target WSDL in the first place. Seems much easier to simply have the local
copy and no wsdlLocation attribute - SCA runtime will happily find the WSDL for you in that case and
you would have saved yourself some work into the bargain ;-)
Yours, Mike.
Re: [DISCUSS] WSDL/XSD imports should use location/schemaLocation as
hints
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jun 8, 2009 at 9:22 AM, Ramkumar R <ra...@gmail.com> wrote:
> Should we consider including the non-SCA resolution mechanism as part of the
> 2.x code
> base same as what we have in 1.x code ?
>
>
> On Wed, May 27, 2009 at 1:37 PM, Ramkumar R <ra...@gmail.com> wrote:
>>
>> Hi All,
>>
>> We had a discuss on this topic (Use of non-SCA Mechanisms for Resolving
>> Artifacts) in the month of March under this thread
>> http://www.mail-archive.com/dev@tuscany.apache.org/msg05956.html
>>
>> What we agreed on as a process to follow for the non-SCA mechanism is.....
>>
>> 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
>>
>> So going by this process, if the artifact specified in the location
>> attribute is not found an error is reported either in Step 5 or 8.
>>
>> I believe, TUSCANY-2906 has been re-opened with an expectation that, the
>> artifacts should be resolved even if the
>> location attribute points to an invalid location. I believe that brings
>> back the question which had in the past as posted here....
>> http://www.mail-archive.com/dev@tuscany.apache.org/msg06028.html
>>
>> Now, the question is that, should we allow the artifact (WSDL/XSD) to get
>> resolved even if the artifact specified in the location
>> attribute is not found anywhere after following the above process?
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>
>
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
Hi Ram
I don't think there is a good reason for them to be different. It
seems that the OASIS spec now adds more detail to the artifact
resolution section of the spec but I don't think this added detail
means that the behaviour changes.
We do though need to run the "step 4" question to ground. So far, in
the context of TUSCANY-2906, it seems that the conversation has come
down to whether step 4 in our list of steps could be considered to be
part of the artifact specific resolution mechanism.
It has been pointed out that the artifact specific and sca
(imports/exports) mechanism should not be mixed. Sounds sensible as if
you were going to rely on the SCA mechanism you would have included an
import for the namespace you require.
It has also been pointed out that the artifact specific mechanism is
extremely flexible and the runtime could decide to look in the current
contribution to find artifacts where the location hint doesn't help
So on this basis do we summarize this by saying that we take step 4 at
face value when it talks about looking in the *current* contribution
and include it in the artifact specific resolution process?
Simon
Re: [DISCUSS] WSDL/XSD imports should use location/schemaLocation as
hints
Posted by Ramkumar R <ra...@gmail.com>.
Should we consider including the non-SCA resolution mechanism as part of the
2.x code
base same as what we have in 1.x code ?
On Wed, May 27, 2009 at 1:37 PM, Ramkumar R <ra...@gmail.com> wrote:
> Hi All,
>
> We had a discuss on this topic (Use of non-SCA Mechanisms for Resolving
> Artifacts) in the month of March under this thread
> http://www.mail-archive.com/dev@tuscany.apache.org/msg05956.html
>
> What we agreed on as a process to follow for the non-SCA mechanism is.....
>
> 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
>
> So going by this process, if the artifact specified in the location
> attribute is not found an error is reported either in Step 5 or 8.
>
> I believe, TUSCANY-2906 has been re-opened with an expectation that, the
> artifacts should be resolved even if the
> location attribute points to an invalid location. I believe that brings
> back the question which had in the past as posted here....
> http://www.mail-archive.com/dev@tuscany.apache.org/msg06028.html
>
> Now, the question is that, should we allow the artifact (WSDL/XSD) to get
> resolved even if the artifact specified in the location
> attribute is not found anywhere after following the above process?
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam
>
--
Thanks & Regards,
Ramkumar Ramalingam
Re: [DISCUSS] WSDL/XSD imports should use location/schemaLocation
as hints
Posted by Simon Nash <na...@apache.org>.
Simon Laws wrote:
> On Wed, May 27, 2009 at 12:29 PM, Mike Edwards
> <mi...@gmail.com> wrote:
>> Ram,
>>
>> I think it would be wise to compare the process described here with the
>> words in the OASIS Assembly spec on precisely this point.
>>
>> Section 11.2.1 of the Public Review draft of the Assembly Spec says:
>>
>> 3468 Where present, artifact-related or packaging-related artifact
>> resolution mechanisms MUST be used
>> 3469 by the SCA runtime to resolve artifact dependencies. [ASM12005] The SCA
>> runtime MUST raise
>> 3470 an error if an artifact cannot be resolved using these mechanisms, if
>> present. [ASM12021]
>>
>> This says that you should not mix the use of "artifact specific" mechanisms
>> with SCA artifact resolution mechanisms. Use one or other but never both.
>>
It is my understanding that the location/schemaLocation attributes for
WSDL/XSD imports provide "hints" to the runtime for locating the artifact
but don't mandate that only the specified location can be searched.
So, in this case, the "artifact specific" mechanisms mandated by the
SCA Assembly spec are very flexible and would allow an implementation
to look in some other location if the artifact is not found at the
specified location. I think they would even allow artifacts in other
locations (e.g., a local cache) to be used in preference to going to
the specified location.
>> The question I ask is - why would you want to mix them?? If the artifacts
>> (such as WSDLs) are there inside one or other contribution, why use
>> @wsdlLocation at all?? And if you're using @wsdlLocation, why would you
>> include a copy of the target WSDL in your contribution? And what happens if
>> the two alternative artifacts are actually different?
>>
This could make sense when the definitive master copy of a schema
or XSD artifact is located at a well-known URL, but this URL might
not be accessible because it is on a server with poor reliability
or the application is running without an internet connection.
In such cases it could be useful to package a local copy of the
artifact with the application for use in cases when the specified
location can't be accessed. In these cases, the master copy would
be used if it is accessible, and the local copy otherwise. Any
difference between these two copies would not be detected.
>>
>> Yours, Mike.
>>
>>
>> Ramkumar R wrote:
>>> Hi All,
>>>
>>> We had a discuss on this topic (Use of non-SCA Mechanisms for Resolving
>>> Artifacts) in the month of March under this thread
>>> http://www.mail-archive.com/dev@tuscany.apache.org/msg05956.html
>>>
>>> What we agreed on as a process to follow for the non-SCA mechanism is.....
>>>
>>> 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
>>>
>>> So going by this process, if the artifact specified in the location
>>> attribute is not found an error is reported either in Step 5 or 8.
>>>
>>> I believe, TUSCANY-2906 has been re-opened with an expectation that, the
>>> artifacts should be resolved even if the
>>> location attribute points to an invalid location. I believe that brings
>>> back the question which had in the past as posted here....
>>> http://www.mail-archive.com/dev@tuscany.apache.org/msg06028.html
>>>
>>> Now, the question is that, should we allow the artifact (WSDL/XSD) to get
>>> resolved even if the artifact specified in the location
>>> attribute is not found anywhere after following the above process?
>>>
>>> --
>>> Thanks & Regards,
>>> Ramkumar Ramalingam
>>
>
> I think this means that step 4 should be removed from the list (I
> don't actually think the code does this at the moment).
>
> Simon
>
>
I don't think the SCA Assembly spec requires step 4 to be removed - see above.
Simon
Re: [DISCUSS] WSDL/XSD imports should use location/schemaLocation as
hints
Posted by Simon Laws <si...@googlemail.com>.
On Wed, May 27, 2009 at 12:29 PM, Mike Edwards
<mi...@gmail.com> wrote:
> Ram,
>
> I think it would be wise to compare the process described here with the
> words in the OASIS Assembly spec on precisely this point.
>
> Section 11.2.1 of the Public Review draft of the Assembly Spec says:
>
> 3468 Where present, artifact-related or packaging-related artifact
> resolution mechanisms MUST be used
> 3469 by the SCA runtime to resolve artifact dependencies. [ASM12005] The SCA
> runtime MUST raise
> 3470 an error if an artifact cannot be resolved using these mechanisms, if
> present. [ASM12021]
>
> This says that you should not mix the use of "artifact specific" mechanisms
> with SCA artifact resolution mechanisms. Use one or other but never both.
>
> The question I ask is - why would you want to mix them?? If the artifacts
> (such as WSDLs) are there inside one or other contribution, why use
> @wsdlLocation at all?? And if you're using @wsdlLocation, why would you
> include a copy of the target WSDL in your contribution? And what happens if
> the two alternative artifacts are actually different?
>
>
> Yours, Mike.
>
>
> Ramkumar R wrote:
>>
>> Hi All,
>>
>> We had a discuss on this topic (Use of non-SCA Mechanisms for Resolving
>> Artifacts) in the month of March under this thread
>> http://www.mail-archive.com/dev@tuscany.apache.org/msg05956.html
>>
>> What we agreed on as a process to follow for the non-SCA mechanism is.....
>>
>> 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
>>
>> So going by this process, if the artifact specified in the location
>> attribute is not found an error is reported either in Step 5 or 8.
>>
>> I believe, TUSCANY-2906 has been re-opened with an expectation that, the
>> artifacts should be resolved even if the
>> location attribute points to an invalid location. I believe that brings
>> back the question which had in the past as posted here....
>> http://www.mail-archive.com/dev@tuscany.apache.org/msg06028.html
>>
>> Now, the question is that, should we allow the artifact (WSDL/XSD) to get
>> resolved even if the artifact specified in the location
>> attribute is not found anywhere after following the above process?
>>
>> --
>> Thanks & Regards,
>> Ramkumar Ramalingam
>
>
I think this means that step 4 should be removed from the list (I
don't actually think the code does this at the moment).
Simon
Re: [DISCUSS] WSDL/XSD imports should use location/schemaLocation
as hints
Posted by Mike Edwards <mi...@gmail.com>.
Ram,
I think it would be wise to compare the process described here with the words in the OASIS Assembly
spec on precisely this point.
Section 11.2.1 of the Public Review draft of the Assembly Spec says:
3468 Where present, artifact-related or packaging-related artifact resolution mechanisms MUST be used
3469 by the SCA runtime to resolve artifact dependencies. [ASM12005] The SCA runtime MUST raise
3470 an error if an artifact cannot be resolved using these mechanisms, if present. [ASM12021]
This says that you should not mix the use of "artifact specific" mechanisms with SCA artifact
resolution mechanisms. Use one or other but never both.
The question I ask is - why would you want to mix them?? If the artifacts (such as WSDLs) are there
inside one or other contribution, why use @wsdlLocation at all?? And if you're using @wsdlLocation,
why would you include a copy of the target WSDL in your contribution? And what happens if the two
alternative artifacts are actually different?
Yours, Mike.
Ramkumar R wrote:
> Hi All,
>
> We had a discuss on this topic (Use of non-SCA Mechanisms for Resolving
> Artifacts) in the month of March under this thread
> http://www.mail-archive.com/dev@tuscany.apache.org/msg05956.html
>
> What we agreed on as a process to follow for the non-SCA mechanism is.....
>
> 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
>
> So going by this process, if the artifact specified in the location
> attribute is not found an error is reported either in Step 5 or 8.
>
> I believe, TUSCANY-2906 has been re-opened with an expectation that, the
> artifacts should be resolved even if the
> location attribute points to an invalid location. I believe that brings
> back the question which had in the past as posted here....
> http://www.mail-archive.com/dev@tuscany.apache.org/msg06028.html
>
> Now, the question is that, should we allow the artifact (WSDL/XSD) to
> get resolved even if the artifact specified in the location
> attribute is not found anywhere after following the above process?
>
> --
> Thanks & Regards,
> Ramkumar Ramalingam