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
