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 <[email protected]> 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: [email protected] > 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 <[email protected]> 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 >
