Ron, You are right that you only need the second argument of define() if your schemaLocation argument is a relative path, e.g.: location="a.xsd". If your location is an absolute path that can be located and opened as with an InputStream, then you don't need to specify the second argument.
Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 07/14/2006 09:48:43 AM: > Frank, > > My WSDL import includes an absolute schema location. In this case, > do I still need to pass the schemaLocation (second argument) to > XSDHelper.define()? > > I'm not exactly sure what you mean by "an absolute location from > which the imported schemaLocations can be resolved". Is this > specifically relevant in this case where the imported schemaLocation > uses a relative reference, say './b.xsd' or 'b.xsd'. Here, the > schemaLocation argument would need to be used to absolutely > reference say 'http://myserver/a.xsd' or 'http://myserver', such > that 'b.xsd' exists in the same directory as 'a.xsd'? > > - Ron > > ----- Original Message ---- > From: Frank Budinsky <[EMAIL PROTECTED]> > To: tuscany-user@ws.apache.org > Sent: Friday, July 14, 2006 9:10:16 AM > Subject: Re: How should XSDHelper.define() handle wsdls/schemas with > schema imports > > > Ron, > > I believe that the XSDHelper.define() method had been tested in the past, > but since we don't have an official JUnit for that, it could possibly be > broken now. But, I think it's more likely that either the > WSDL2JavaGenerator is causing the problem, or maybe the imported schema > "b" just can't be resolved. Does the WSDL import include a schema > location. > > You can easily test XSDHelper.define() by calling it with the WSDL file, > and then iterating through the list of Type's that it returns to make sure > that it includes types in both URIs "a" and "b", Make sure that when you > call define() you pass it a schemaLocation String (second argument) that > is an absolute location from which the imported schemaLocations can be > resolved. > > Good luck. > > Frank. > > Ron Gavlin <[EMAIL PROTECTED]> wrote on 07/14/2006 08:36:10 AM: > > > Frank et al., > > > > Do you know if the scenario in which a WSDL with targetNamespace "a" > > imports a schema with targetNamespace "b" has been tested? The > > WSDL2JavaGenerator doesn't seem to handle this scenario. I'm not > > sure if it is a XSDHelper problem or a WSDL2JavaGenerator problem. > > > > - Ron > > > > ----- Original Message ---- > > From: Frank Budinsky <[EMAIL PROTECTED]> > > To: tuscany-user@ws.apache.org > > Sent: Thursday, July 13, 2006 2:45:18 PM > > Subject: Re: How should XSDHelper.define() handle wsdls/schemas with > > schema imports > > > > > > XSDHelper.define() should also define all the imported schemas. If > that's > > not happing, maybe the imported schemas can't be found so it's failing > to > > resolve. > > > > Frank. > > > > Ron Gavlin <[EMAIL PROTECTED]> wrote on 07/13/2006 01:16:59 AM: > > > > > I have a WSDL which imports a schema, that itself imports two add'l > > > schemas. When I invoke XSDHelper.define() passing the WSDL as a > > > parameter, should the nested schema imports be resolved/defined or do > > > each of these "imported" schemas need to be "defined" explicitly? It > > > appears the WSDL2JavaGenerator currently expects XSDHelper.define() to > > > > resolve/define the "imported" schemas which does not appear to work. > > > > > > Best regards, > > > > > > - Ron > > > > > > --------------------------------------------------------------------- > > > 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] > > > > --------------------------------------------------------------------- > > 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] > > --------------------------------------------------------------------- > 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]
