Ah! I understand, now. Rick is correct. The Folder type is not used anywhere, therefore a Java class is not generated for it.
Russell Butek [EMAIL PROTECTED] "Hansen, Richard" <[EMAIL PROTECTED]> on 02/04/2002 12:02:47 PM Please respond to [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: RE: about method overloading Maybe I am missing something? Given that the input param is type="types:Object" I would not have any reason to expect the Java code to be generated with a Folder. Folder maybe in the types section but it certainly does not appear as the message type. Rick Hansen > -----Original Message----- > From: St-Germain, Sylvain [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 04, 2002 11:54 AM > To: [EMAIL PROTECTED] > Subject: RE: about method overloading > > > Mmm... I was under the impression that both concepts were intimately > related... > I have complex types that do inherit from other complex > types, my messages > are defined using the base type as below: > > <complexType name="Object"> > <sequence> > [...] > </sequence> > </complexType> > > <complexType name="Folder"> > <complexContent> > <extension base="types:Object"> > <sequence> > [...] > </sequence> > </extension> > </complexContent> > </complexType> > > <message name="addInput"> > <part name="input" type="types:Object"/> > </message> > <message name="addOutput"> > <part name="result" type="xsd:string"/> > </message> > > <operation name="add"> > <input message="cm:addInput"/> > <output message="cm:addOutput"/> > </operation> > > > Doing so, doesn't trigger the generation of the Folder object. > > thanks, > Sylvain. > > > > -----Original Message----- > From: Russell Butek [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 04, 2002 11:46 AM > To: [EMAIL PROTECTED] > Subject: Re: about method overloading > > > I'm confused. Are we talking about overloaded methods or > inherited types? > Show me your WSDL. > > Russell Butek > [EMAIL PROTECTED] > > > "St-Germain, Sylvain" <[EMAIL PROTECTED]> on > 02/04/2002 10:16:52 > AM > > Please respond to [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > cc: > Subject: about method overloading > > > > Hi all, > > I came across this post that discuss an issue regarding > method overloading. > I need to make up my mind about the use of method overloading. It > certainly > comes in handy if you have a dozen apis to expose for a dozen > of objects. > > Playing with wsdl2Java shown me that it does not (as of Jan > 30th build) > generates stub classes for derived complex types because they are not > explicitly referenced to by any messages, instead the > messages refer to the > base type, Object. > > - Debug info from wsdl2Java > > org.apache.axis.wsdl.toJava.DefinedType > QName: http://xxx/xsd:Object > isReferenced? true > [...] > > org.apache.axis.wsdl.toJava.DefinedType > QName: http://xxx/xsd:Folder > isReferenced? false > [...] > > This seems to be a strong limitation. As a consumer of a > service I need > the > derived classes to be generated even though they are not > directly used by > the messages. > > Would the fix simply be for WSDL2Java to see that Folder is a > derived type > of Object and set his "isReferenced" attribute to true to get > the class > generated? Or else should I be building my wsdl otherwise for this to > happen? > > In general, how is method overloading accepted/perceived? It > looks like > being a good thing to me! > > Regards, > Sylvain. > > > -----Original Message----- > From: Russell Butek [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 25, 2002 10:18 AM > To: [EMAIL PROTECTED] > Subject: Re: Bugs in AXIS Alpha 3 version > > > 2. overloaded methods problem. This is a known problem. > We've fixed our > bug this week. Unfortunately, we depend on WSDL4J which also > has a bug. > They've been notified of it. Now, instead of only getting > one registerChar > method, you get one of them twice. I would caution you on > using overloaded > methods if you can avoid it. There are a number of places > where operations > are referred to only by name, not by signature (deploy.wsdd). > So even if > this particular bug is fixed, I worry that there may be > deeper issues that > we'll run into. > > > This message may contain privileged and/or confidential > information. If > you > have received this e-mail in error or are not the intended > recipient, you > may not use, copy, disseminate or distribute it; do not open any > attachments, delete it immediately from your system and > notify the sender > promptly by e-mail that you have done so. Thank you. > > > This message may contain privileged and/or confidential > information. If you > have received this e-mail in error or are not the intended > recipient, you > may not use, copy, disseminate or distribute it; do not open any > attachments, delete it immediately from your system and > notify the sender > promptly by e-mail that you have done so. Thank you. >
