Title: RE: "Chicken-Egg" problem with Java2WSDL/WSDL2Java

Here's how I get around the problem.  I use Ant to run WSDL2Java.  The target that does that tells WSDL2Java to send the files it generates to a directory called "gen".  After that, Ant copies the files I want into my "src" directory.

> -----Original Message-----
> From: James Kojo [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 16, 2002 6:47 PM
> To: [EMAIL PROTECTED]
> Subject: Re: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
>
>
>
> Has this problem been solved? Is there a way to generate the
> server side code
> without over-writing a pre-existing implementation?
>
> THanks,
>
> James
>
>
> "Rathert Jonas (Platinion)" wrote:
>
> > 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:[EMAIL PROTECTED]
> >     http://www.platinion.de/
>



***********************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
************************************************************************************

Reply via email to