I would like to just summarize, the current functionality used to resolve WSDL and XSD's using WSDLResolver and XSDResolver and see how we want to handle the situation further.
In case of WSDL we have two approaches that are currently used.... a) For the WSDL that's been specified in the SCDL file we use the SCA resolution mechanism always. b) For the WSDL imports using @wsdlLocation attribute, we now use the non-SCA mechanism as the first preferred approach to identify the artifacts, if the artifact is not found using the non-SCA mechanism then we try to use the SCA mechanism to resolve the artifacts. Similarly, in case of XSD we have two approaches again.... a) For inline XSD's we use the SCA resolution mechanism always. b) For XSD imports using @schemaLocation attribute, we use the non-SCA mechanism as the preferred first approach and use the SCA mechanism if its not resolved with the non-SCA mechanism. The reason, why I had to revert some changes in XSDResolver is for the reason that I had accidentally made the inline schemas to follow the norms of using non-SCA mechanism as first approach, which is invalid and had to revert the code and keep these norms only for XSD imports. The XSDResolver allows us to specify absolutePath's and URL's in the @schemaLocation attribute and resolves them accordingly. But same is not the case with WSDL @wsdlLocation attribute, were only relativePaths are allowed to resolve even with the non-SCA mechanism. My question here is that, are we also expecting the WSDL @wsdlLocation attribute to support absolutePath's. -- Thanks & Regards, Ramkumar Ramalingam
