Re: "Chicken-Egg" problem with Java2WSDL/WSDL2Java

[James Kojo <jk...@bluemartini.com>]

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:rathert.jonas@platinion.de
>     http://www.platinion.de/

Re: "Chicken-Egg" problem with Java2WSDL/WSDL2Java

[Chad <ch...@optusnet.com.au>]

How I solve the problem is
I generate all the classes and redirect to my classes at the appropriate
points using sed 
 
For the web service classes I have my own implementation that implements
the interface and I sed the generated skeleton class replacing the
reference to the generated impl class with a reference to my class. Here
is the one line of sed:
	sed
"s/$packageOfWebServiceClasses."$serviceName"SoapBindingImpl/$myImpl/g"


For the data classes I subclass the generated classes. To  ensure my
classes are constructed 
I modify the Stud class. Specifically I replace references to the
generated data classes where they are registered for (de)serialization
with references to my data classes. The sed for this is:
	sed "s/cls = $generatedClass\.class/cls = $myclass.class/g"


So I always use all the generated code except for the trivial service
Impl class and if there is a mismatch between my classes and the wsdl it
turns up in as an understandable compile error

WSDL2Java could support this if anyone had any time (I dont so why
should any one else) by for example  allowing the specification of and
alternative service implementation classes and the specification of
alternative implementations of the data classes (which must be
subclasses though)


I am moving away from extending the data classes to wrapping them. This
makes extending class non leaf classes possible and everything a bit
clearer. It will just mean that I have to do the wrapping and write the
wrapping classes which may be tedious.


Another idea ,which may have been mooted earlier, would be an
implementation of the (de)serializers that did not rely on metadata eg
org.apache.axis.description.FieldDesc in the data classes but built this
up at runtime by refection (it wouldn't be too slow because you would
only have to do it once). Then WSDL2Java could optionally generate
interfaces rather than implementations of the data classes. The hand
coded data classes could just implement these interfaces. [ I not sure
what to do with the super equals and super hashcode methods but I think
the idea still flies]


Chad