You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Martin Jericho <ma...@radiocity.com.au> on 2002/08/01 02:20:03 UTC

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" <Bo...@CapitalStream.com>
To: <ax...@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.
>