Hi, I was recently looking into http://issues.apache.org/jira/browse/TUSCANY-1343 and I am able to relate well with all of what is being discussed here. From whatever I understand from that JIRA it is desired that the package-processor that is processing an SCA contribution be given the responsibility of locating and loading the xsd or wsdl. i.e. the WSDLProcessor does not take on the locating and loading. Asking for this seems consistent with our overall artifact reading and resolution design but I couldn't quite figure out a clean way of achieving this. What Huang is suggesting for a way out of this seems like something worth exploring. Thoughts ?
Thanks - Venkat On 7/27/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > Jean-Sebastien Delfino wrote: > > Comments and questions inline. > > > > Mike Edwards wrote: > >> Hi, > >> > >> A few thoughts.... > >> > >> > >> <snip> > >> >> 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? > >> > >> Well, it seems valid to me to go use the SCA resolution mechanism - > >> it is simple enough to say, either use the WSDL or XML approach (and > >> require a location) but if there is no location, then this isn't > >> going to work and SCA takes over. I note that if the location is > >> left out in the case of the included/imported file being in the same > >> contribution as the source file, then things are simple and the SCA > >> rules will find it. > >> > >> If it is elsewhere, then SCA at least defines an algorithm to follow > >> to attempt to find the referenced file. > > > > How about this then: > > - if the location is not specified you get the first WSDL file we find > > matching the namespace in the current contribution or in a > > contribution imported by an SCA <import> > > - if you're not happy with that (because for example you have multiple > > WSDLs sharing the same namespace), please specify a correct location > > in your WSDL > > I should have said XSD here instead of WSDL as locations are mandatory > in WSDL... > > > > > Is this too simplistic? Do you see any realistic scenarios that we > > wouldn't be able to support with this approach? > > > >> > >> > >> > 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. > >> > >> Why actually load anything before it is clearly required? > > > > I'm not quite following yet, how does one know that file X.wsdl is > > clearly required? > > > >> But once it is loaded, keep it around. This should be true for all > >> artifacts. > > > > +1 for all artifacts that we handle ourselves, but WSDL4J and the > > XmlSchema lib do not seem to support this. Has anybody raised this > > issue to them? > > > > > >> > >> Yours, Mike. > >> > > > -- > 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]
