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
