axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Thomson <stu...@swtsoftware.com>
Subject Re: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
Date Sat, 03 Aug 2002 15:26:45 GMT
Another option might be --rpc to generate only the classes required for
the jaxrpc and soap stuff, ie stub, skeleton, service and service locator.

This would be more in line with the code generated by other remoting technologies.

I have no intention of letting axis mess with my lovingly hand crafted beans.

butek@us.ibm.com wrote:
> 
> Docs? Docs?! We can ALWAYS use help with the docs!
> 
> I agree that it could be useful for WSDL2Java to NOT overwrite things, but there is stuff
in our
> generated beans that make life a whole lot easier for the runtime that the original beans
won't
> have. Also, if you have an --overwrite switch and forget to turn it off when you change
the WSDL,
> then you'll get code that doesn't match the WSDL and it could easily take hours to realize
that
> you forgot one simple switch. So I don't like the idea of an --overwrite switch.
> 
> What would be more useful would be a switch for --client or --server. The --client switch
would
> generate what's needed on the client. The --server switch would ONLY generate what's
needed on the
> server. Today --server generates EVERYTHING. This isn't quite what you want, though,
since there
> is stuff (like the interface and the beans) that will be generated on both sides. You
need yet
> another tool, call it Java2AXISDeploy, which takes your existing classes and generates
the WSDL to
> export to clients, and the deploy.wsdd/undeploy.wsdd files.
> 
> If you want to get a rough idea of the architecture of WSDL2Java, look at
> http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/integration-guide.html#WSDL
plug.
> It's yet more documentation that's not quite complete, but it's something to get you
started if
> you're interested.
> 
> Russell Butek
> butek@us.ibm.com
> 
> Please respond to axis-user@xml.apache.org
> 
> To: "'axis-user@xml.apache.org'" <axis-user@xml.apache.org>
> cc:
> Subject: RE: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
> 
> Actually, if someone on the Axis team can help me hit the ground running, I
> could probably justify spending the time on-the-job and contribute to the
> project as well. I wouldn't mind doing the docs either. (Hear that guys?)
> 
> Anyway, we'll see what shakes out.
> 
> -----Original Message-----
> From: Martin Jericho [mailto:martin.j@radiocity.com.au]
> Sent: Wednesday, July 31, 2002 5:20 PM
> To: axis-user@xml.apache.org
> Subject: Re: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
> 
> Allowing existing classes to be used in SOAP calls is so fundamental that it
> will almost certainly be implemented at some stage, so if your workaround
> works, and you don't have time (like the rest of us) to contribute to the
> axis project, the best thing to do is probably just wait until someone else
> implements it and put up with the performance hit and ugly reflection stuff
> in the mean time.  You might want to call it "least-bad practices".
> 
> ----- Original Message -----
> From: "Bob Combs" <BobC@CapitalStream.com>
> To: <axis-user@xml.apache.org>
> Sent: Thursday, August 01, 2002 3:30 AM
> Subject: RE: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
> 
> > That's essentially what I'm attempting to do, the issue is that
> > there's no place to "hook" in the existing Code base since axis
> > re-writes bloody everything. If it used or extended
> the
> > existing bean classes I wouldn't have any problems.
> >
> > I've worked around the problem by using reflection to copy the axis
> > generated version of the bean to my original bean (a utility I had
> > anyway) in the xxSoapBindingImpl.java class. Then, I'm able to call
> > the origingal service definition with a recognized bean class. This
> > seems like a pretty sloppy way to do things.
> >
> >
> > -- On to the suggestion for improvement. (If I could get some help
> figuring
> > out how WSDL2Java works I'd gladly lend a hand on this)
> >
> > It'd be much handier to be able to specify an existing java
> class/interface
> > as a service definition and have a tool generate .wsdd and any
> > axis-necessary classes off the class (and any dependent
> classes/interfaces)
> > rather than generate everything wholesale off a .wsdl file.
> >
> > If this were the case you could automagically build all the
> > web-service necessary components with and ant target instead of
> > hand-editing generated files to properly proxy existing code.
> >
> > -----Original Message-----
> > From: St-Germain, Sylvain [mailto:Sylvain.StGermain@cognos.com]
> > Sent: Wednesday, July 31, 2002 10:14 AM
> > To: axis-user@xml.apache.org
> > Subject: RE: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
> >
> >
> > I understand.
> >
> > Something I read on the list though, is that when people have an
> > implementation, they simply use the generated server-side code as a
> > proxy
> to
> > the existing implementation.
> >
> > Sylvain.
> >
> > -----Original Message-----
> > From: Bob Combs [mailto:BobC@CapitalStream.com]
> > Sent: Wednesday, July 31, 2002 12:30 PM
> > To: 'axis-user@xml.apache.org'
> > Subject: RE: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
> >
> >
> > Actually, I consider the generation scenario I'm attempting to be
> > about
> the
> > simplest case possible for passing bean classes across a web service.
> > I simply want the service to use (or extend) the bean I coded, not
> > generate its own from scratch off the wsdl for the service-side
> > components. Seems reasonable to me. Perhaps I'm missing something
> > really obvious here, but mining the docs doesn't seem to indicate any
> > solutions.
> >
> > -----Original Message-----
> > From: St-Germain, Sylvain [mailto:Sylvain.StGermain@cognos.com]
> > Sent: Wednesday, July 31, 2002 6:20 AM
> > To: axis-user@xml.apache.org
> > Subject: RE: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
> >
> >
> > Notwithstanding the fact that WSDL2Java could be more flexible,
> > shouldn't complex generation scenarios like yours be achieved using
> > Ant tasks for example?
> >
> > Axis already provide a wsdl2java task, using Ant you could customize
> > the process to the extent you need.
> >
> > ...my 2 cents.
> > Sylvain.
> >
> >
> > -----Original Message-----
> > From: Bob Combs [mailto:BobC@CapitalStream.com]
> > Sent: Tuesday, July 30, 2002 4:33 PM
> > To: 'axis-user@xml.apache.org'
> > Subject: RE: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
> >
> >
> > I'm having many of the same issues.
> >
> > It seems like WSDL2Java's purpose has become muddled.
> >
> > Perhaps a Java2WebService (or some other name) util is in order to
> > remove some of the confusion and to better encapsulate functionality.
> >
> >  Java2WebService would generate .wsdl, the SOAP bindings, and the
> > .wsdd file.
> >
> >  WSDL2Java would just create client code.
> >
> > Anyway, just a thought.
> >
> > -----Original Message-----
> > From: Rathert Jonas (Platinion) [mailto:Rathert.Jonas@PLATINION.DE]
> > Sent: Tuesday, July 30, 2002 4:26 AM
> > To: 'axis-user@xml.apache.org'
> > Subject: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
> >
> >
> > Hi,
> >
> > a few days ago I asked for "best practices" when developing
> > WebServices using an existing RMI interface and implementation.  I
> > understood that
> this
> > is not completely supported by Axis the way I want it (thanks Martin
> > for
> the
> > pointer to the "WSDL2Java Design Issue" thread on this list), and now
> > I
> try
> > a slightly different approach.
> >
> > However, again I ran into a situation where I need some assistance.
> >
> >  - I have an interface where one method returns a Bean type which
> >    is in another package:
> >
> >      package plt.foo;
> >      import plt.baz.MyBean;
> >      public interface Bar {
> >          public MyBean getBean();
> >      }
> >
> >  - I also have the baz.MyBean class implementation (of course) and
> >    an implementation of the interface:
> >
> >      package plt.foo;
> >      import plt.baz.MyBean;
> >      public class BarImpl implements Bar {
> >          public MyBean getBean() {
> >              MyBean b = new MyBean();
> >              // do something with b
> >              return b;
> >          }
> >      }
> >
> > I want to make this method available as a WebService.  I compile
> > everyting and call Java2WSDL the following way with the following
> > arguments:
> >
> >  -obar.wsdl -nurn:Bar -lhttp://localhost:8080/axis/service/Bar
> > plt.foo.Bar
> >
> > The WSDL-file looks good, it contains the compleType as I expected.
> >
> > Now I call WSDL2Java with the "-S true" option using the generated
> > WSDL file to get the server skeletons and deploy.wsdd etc.
> > Unfortunately, this process will overwrite the source of
> > plt.baz.MyBean, since the WSDL contains contains a complexType
> > "MyBean" in namespace "http://baz.plt".
> >
> > I do not want this and worked around this using the -N option - here
> > are the complete WSDL2Java arguments:
> >
> >  -Nurn:Bar=plt.rmi -Nhttp://baz.plt=plt.rmi -S true bar.wsdl
> >
> > (I want everything that is created to be placed in the plt.rmi
> > package, especially the MyBean implementation to be used in the
> > client).
> >
> > Now everything looks good, I got a new MyBean class in package plt.rmi
> which
> > I should use in the client and I keep my old plt.baz.MyBean which is
> > used
> in
> > the server-side implementation.  Unfortunately the
> > server skeleton and the deploy.wsdd now refer to plt.rmi.MyBean - so I
> > can not use my existing implementation which uses plt.baz.MyBean. I
> > can not make my own implementation use the plt.rmi.MyBean, sine this
> > does not even exist at the very beginning.
> >
> > This seems a little bit like a chicken-egg-problem to me: On the one
> > hand, I need an implementation of the MyBean _before_ creating the
> > WSDL, on the other hand, my actual imlpementation should then use an
> > implementation of plt.rmi.MyBean, which I do not have in the
> > beginning.
> >
> > What I actually want is to call WSDL2Java twice:
> >
> >  - first in "client mode only" which generates plt.rmi.MyBean,
> >    the client stubs etc.
> >
> >  - second in "server mode only" which generates the server side
> >    skeletons and (un)deploy.wsdd _only_.  I would _not_ map
> >    the NS http://baz.plt to package plt.rmi here, instead I would
> >    use existing classes where possible.
> >
> > Unfortunately, this does not seem to work with the curren WSDL2Java.
> >
> > Right now I found some other solutions to this problem, though the
> > only one where I do not have to change some of the generated files is
> > to to accept that my Bean source gets overwritten (which I do not
> > really like because my "original" Bean did contain a second
> > constructor for convenience) every time I recreate the WSDL and/or
> > client stubs.
> >
> > Is there any other way around this?  Or is it more or less a problem
> > of my
> > (unrealistic?) requirements?
> >
> > Sorry for bothering again.  If I had more experience with all this,
> > I'd
> like
> > to help with improving the docs at least to show "use cases" or
> > "correct usage" for all this.  Maybe I can provide some if I
> > understand what I am actually doing... ;-)
> >
> > Thanks in advance!
> >
> > Regards
> >
> >   Jonas
> >
> > --
> >     Jonas Rathert
> >
> >     PLATINION GmbH
> >     A Company of the Boston Consulting Group
> >
> >     Im Mediapark 5, 50670 Cologne/Germany
> >     Tel.    +49 221. 58 95 83 04
> >     Fax     +49 221. 589 20 51
> >     mailto:rathert.jonas@platinion.de
> >     http://www.platinion.de/
> >
> > 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.
> >

Mime
View raw message