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
