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
>