WSDL2Java is fully JAX-RPC compliant.
JAX-RPC does not give you 'portable stubs' - i.e. you must use Axis WSDL2Java output with Axis only, not the RI or any other implementation. Axis WSDL2Java should ignore any non-SOAP bindings, and if it doesn't it is a bug I would say. I do not much like Russell idea of trying to take the WSDL2 framework out of Axis. :-( -- Tom Jordahl Macromedia Server Development -----Original Message----- From: Paul Fremantle [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 01, 2002 9:23 AM To: [EMAIL PROTECTED] Subject: Re: [axis] WSDL2Java enhancements for WSIF Russell I want to convince you! :-) Wouldn't it be better to make the WSDL2Java tool fully JAX-RPC compliant. One of the aspects of the dynamic option is that the code built can be used with any JAX-RPC compliant implementation. As regards the non-SOAP bindings - I can envisage scenarios where a WSDL with multiple bindings is being used by Axis and using only Axis. This is completely standard use of WSDL, which is not guaranteed to either have or not have bindings of any type. It is fully extensible. So a non-WSIF user might want to use Axis with WSDL generated by WSAD-IE, or someone else, that includes a SOAP binding and a non-SOAP binding. Shouldn't Axis support building client code for any valid WSDL? Paul ----- Original Message ----- From: "Russell Butek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 01, 2002 1:47 PM Subject: Re: [axis] WSDL2Java enhancements for WSIF > > > > > I could, perhaps, be convinced to add a --dynamic flag, which would only > generate the SEI and types. But your other point isn't sensible for > today's AXIS. AXIS is a SOAP engine. There is no reason for an AXIS tool > to support something that AXIS itself doesn't support. > > However, ... uh, ... let me give you a quick architecture of the tool, > first. There are two levels: WSDL2 which is the base framework and the > symbol table; WSDL2Java extends this base and adds the emitters. I suspect > that WSDL2Java falls apart on WSIF's WSDL in the symbol table itself, not > in the emitters. (Could you send me one of your WSDL files so I can > verify?) > > Anyway, back to the 'however'... since it's the base framework that may be > failing for you, this is another reason to move the base framework - the > WSDL2 bit - into its own project. THIS thing should be able to handle all > bindings (or at least have hooks for extensions to add specific binding > info). An extension could do what it likes with the bindings handed to it. > For instance, AXIS's WSDL2Java could throw an UnsupportedException if it > sees non-SOAP bindings. WSDL2WSIF would accept all bindings that it > understands. > > So I'm still hesitant to change the tool as it sits today inside of AXIS. > But if we move WSDL2 outside of AXIS (leaving the WSDL2Java bits inside > AXIS), then I would be much more comfortable with your suggestions. We > could then create, for WSIF, a WSDL2WSIF tool, which could essentially be > an extension of WSDL2Java which: > 1. turns off the UnsupportedException and deals with the new bindings. > 2. only generates the SEI and types. > > Russell Butek > [EMAIL PROTECTED] > > > "Paul Fremantle" <[EMAIL PROTECTED]> on 10/01/2002 03:50:06 AM > > Please respond to [EMAIL PROTECTED] > > To: <[EMAIL PROTECTED]> > cc: > Subject: Re: [axis] WSDL2Java enhancements for WSIF > > > > Russell > > I don't believe these extra enhancements to be just valid for WSIF. > > The JAX-RPC spec allows the usage of dynamic proxies, where there is no > stub > class. This is the model we use in WSIF, and in this model, there is no > requirement to generate stub classes. > > Secondly, there is nothing in the WSDL spec to say that you will only ever > get SOAP bindings, so if WSDL2Java falls over with other bindings thats a > bug. > > I believe these changes are valid enhancements to a tool that should be > useful for any JAX-RPC implementation. > > Paul > > > ----- Original Message ----- > From: "Russell Butek" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Monday, September 30, 2002 4:16 PM > Subject: RE: [axis] WSDL2Java enhancements for WSIF > > > > > > > > > > > > I don't like lots of extra options on WSDL2Java just for WSIF > (particularly > > if you'll always use those options in WSIF), so I prefer a new tool. If > we > > go the route of a new tool, it should be under the WSIF umbrella, not > AXIS. > > > > Russell Butek > > [EMAIL PROTECTED] > > > > > > "Anthony Elder" <[EMAIL PROTECTED]> on 09/30/2002 09:53:29 AM > > > > Please respond to [EMAIL PROTECTED] > > > > To: [EMAIL PROTECTED] > > cc: > > Subject: RE: [axis] WSDL2Java enhancements for WSIF > > > > > > > > > > Absolutely, fixing WSDL2Java so it doesn't abend is probably what I > really > > meant but just described badly. Ignoring the extra WSDL should work fine. > > > > I don't know about a new API and a WSDL2WSIF command, it seems a little > > over kill when all WSIF needs is to suppress writing out the stub > classes. > > How about then a -xs switch to say don't generate stubs. Later other > > options such as -xt (don't generate types) could be added if anyone ever > > wanted it. Actually to do this would probably require creating the new > API > > anyway with new methods on the Emiter and Parser classes. If there was a > > new WSDL2WSIF command, would it be part of AXIS or WSIF? > > > > ...ant > > > > Anthony Elder > > [EMAIL PROTECTED] > > Web Services Development > > IBM UK Laboratories, Hursley Park > > (+44) 01962 818320, x248320, MP208. > > > > > > Russell Butek/Austin/IBM@IBMUS on 30/09/2002 15:08:43 > > > > Please respond to [EMAIL PROTECTED] > > > > To: [EMAIL PROTECTED] > > cc: > > Subject: RE: [axis] WSDL2Java enhancements for WSIF > > > > > > > > > > > > > > > > Seems to me that we need a new extension - WSDL2WSIF. This could either > > extend WSDL2Java or extend the base framework WSDL2. > > > > If I could get some more information from you folks about what you > actually > > generate, I could help create this extension (next week - this week I'm > > rather strapped for time). > > > > Russell Butek > > [EMAIL PROTECTED] > > > > > > Tom Jordahl <[EMAIL PROTECTED]> on 09/30/2002 08:46:20 AM > > > > Please respond to [EMAIL PROTECTED] > > > > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > > cc: > > Subject: RE: [axis] WSDL2Java enhancements for WSIF > > > > > > > > Anthony, > > > > I would think that a different approach would be much better: > > > > 1. Fix WSDL2Java so that it either ignores or correctly processes the > WSDL > > you run it. > > > > Then > > > > 2. Enhance WSDL2Java with an API that gives more control over which > > artifacts you want/need generated. This MAY be reasonable to expose on > the > > command line, but lets not give a poor user too many obscure options. :-) > > > > This sounds like the kind of changes that would be more widely beneficial > > to everyone, don't you think? > > > > -- > > Tom Jordahl > > Macromedia Server Development > > > > > > > > -----Original Message----- > > From: Anthony Elder [mailto:[EMAIL PROTECTED]] > > Sent: Monday, September 30, 2002 7:53 AM > > To: [EMAIL PROTECTED] > > Subject: [axis] WSDL2Java enhancements for WSIF > > > > > > In WSIF we use the AXIS WSDL2Java tool to generate the interfaces and > > complex type classes that WSIF requires. > > > > Currently WSDL2Java will always also generate the stub classes that WSIF > > does not require, and also when using WSDL that includes some of the WSIF > > specific bindings WSDL2Java will abend. This isn't a problem as the abend > > happens after the classes WSIF requires have been written out, and its > easy > > enough to delete the stubs WSIF doesn't use, but it would be nice from > the > > WSIF perspective if WSDL2Java had a parameter which said to only to > > generate the WSIF required classes. > > > > If we made this change, say adding a -w switch to WSDL2Java and all the > > other associated changes to do this, would this be considered for adding > to > > the standard AXIS WSDL2Java? > > > > ...ant > > > > Anthony Elder > > [EMAIL PROTECTED] > > Web Services Development > > IBM UK Laboratories, Hursley Park > > (+44) 01962 818320, x248320, MP208. > > > > > > > > > > > > > > > > >
