axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Combs <B...@CapitalStream.com>
Subject RE: "Chicken-Egg" problem with Java2WSDL/WSDL2Java
Date Wed, 31 Jul 2002 16:30:14 GMT
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.

Mime
View raw message