Hi, Raymond: I also noticed the same problem when testing Tuscany two days ago. I'm not familiar with WSDL4j. When I looked into the codes, my fist response is replacing WSDLLocator, as you mentioned. While the ugly thing is that WSDLLocator return InputSource instead of some sort of placeholder/delegate. We rough thought is use some sort of lazy-import/include way to get around this problem(If you can't stop the aggressive resolveing, you cheat it). So you might want a dummy WSDLDefinition for return instead of implementing a dummy InputSource. You just record the location of the wsdl file in the read() phase, and resolve all the recorded wsdl files in the resolve() phase, then replace the dummies with the real ones. This can promise you to have the right InputSource. The last thing I want to do is implements your own WSDLFactory and WSDLReader by subclassing the default.
What's more, SDO has its XSDHelper to parse all the xsd files to load all SDO types they need ( That is to say, some SDO implementation may registered their own XSDDocumentProcessor). So the Tuscany may need some kind of mechanism to allow delegating the resolving of namespace in wsdl to SDO's TypeHelper.(That is why I prefer the use of namespace to schemaLocation) Another problem we saw in WSDL in Tuscany is WSDLOperation. Where multiple output parts is not supported explicitly. Then what if some service return an array of objects as return? ----- Original Message ----- From: "Raymond Feng" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, July 25, 2007 10:29 AM Subject: Re: Resolving WSDL/XSD import/include for SCA contributions > Hi, > > Please see my comments inline. > > Thanks, > Raymond > > ----- Original Message ----- > From: "Jean-Sebastien Delfino" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Tuesday, July 24, 2007 6:46 PM > Subject: Re: Resolving WSDL/XSD import/include for SCA contributions > > >> Two questions inline. >> >> >> Raymond Feng wrote: >>> Hi, >>> >>> I'm working on the artifact processing of WSDL/XSD from SCA >>> contributions, especially for the import/include directives. I would like >>> to share what I have so far to get your feedback. >>> >>> Let's assume we have the following artifacts ([1][2]). >>> >>> * helloworld-service.wsdl (definition) imports helloworld-interface.wsdl >>> * helloworld-interface.wsdl (inline schema) imports greeting.xsd >>> * greeting.xsd includes name.xsd >>> >>> For the import/include, we could have different ways to use the >>> "location" attribute for a WSDL <import>. Please note the SCA spec says >>> the explicit location attribute should be honored. If it's not present, >>> then we use the namespace-based resolution defined by SCA. >>> >>> 1. location="helloworld-interface.wsdl" (relative to the base document >>> where the import is defined) >>> 2. location="/wsdl/helloworld-interface.wsdl" (relative to a SCA >>> contribution) >>> 3. location="http://example.com/helloworld-interface.wsdl"; (absolute URL >>> pointing to an external resource) >>> 4. location="" or location is not present: Use the namespace to resolve >>> the imported definition >> >> Is location="" even valid? I didn't think so. > > I have clarified this on the follow-up e-mail. The location attribute is > required for <import.wsdl>. "" doesn't seem to be a valid URI. > > The absence of schemaLocation for <xsd:import> and <xsd:include> are valid > though. > >> >>> >>> We have two options here: >>> >>> a) Plugin a tuscany-specific resolver for WSDL4J >>> (javax.wsdl.xml.WSDLLocator) and XmlSchema >>> (org.apache.ws.commons.schema.resolver.URIResolver). >>> >>> This option can handle location case 1, 2 and 3. For 2, we probably need >>> some context from the contribution service. >>> >>> The difficulty is that both resolvers expect to take an InputSource. For >>> location case 4 (empty or not present), we don't have a corresponding >>> InputSource. >> >> I was going to respond with a long list of pros-cons for both options, >> then deleted all my comments to ask a simple question :). Why can't we >> return an InputSource for the contents of the imported document? >> > > Well, for the import/include that can be resolved to a document, we return > the InputSource. I have said that it works for location case 1, 2 and 3. But > if the import/include only doesn't have the schemaLocation attribute, what > InputSource should we return? > > A related question, for an artifact processer that loads multiple artifacts > following the import/include directives, how can we avoid the duplicate > loading? For example, we have a.wsdl imports b.wsdl, both a.wsdl and b.wsdl > are in the same contribution and they are processed by the WSDL artifact > processor. We probably don't want to load b.wsdl twice in this case. > >>> To make WSDL4J happy, we might be able to provide a dummy InputSource >>> pointing to a byte array which contains the empty definition (AFAIK, null >>> InputSource won't work) and then resolve the imported definition by QName >>> during the resolve() phase. >>> >>> b) Disable the import/include resolving feature and re-link the related >>> artifacts by Tuscany >>> >>> There are two challenges: >>> >>> How to disable the aggressive resolving of import/include? >>> How to re-link the artifacts after the fragments are loaded? >>> >>> WSDL4J: We can disable the import processing by WSDL4J and then resolve >>> the imported artifacts in the different step. Some of the elements are >>> "undefined" and we have to navigate the WSDL4J model and resolve them. >>> During the procedure, we can use the location as a key to constrain the >>> scope of resolution. >>> >>> XmlSchema doesn't seem to have a way to disable the aggressive resolving. >>> >>> What do you guys think? Any opinions are welcome. >>> >>> Thanks, >>> Raymond >>> >>> [1] >>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/wsdl >>> [2] >>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl-xml/src/test/resources/xsd >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> >> -- >> Jean-Sebastien >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
