Re: [DISCUSS] Use of Existing (non-SCA) Mechanisms for Resolving Artifacts

[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

[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

[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

[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

[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

[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

[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

[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