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@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, July 31, 2002 12:30 PM
To: 'axis-user@xxxxxxxxxxxxxx'
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@xxxxxxxxxx]
Sent: Wednesday, July 31, 2002 6:20 AM
To: axis-user@xxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, July 30, 2002 4:33 PM
To: 'axis-user@xxxxxxxxxxxxxx'
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@xxxxxxxxxxxx]
Sent: Tuesday, July 30, 2002 4:26 AM
To: 'axis-user@xxxxxxxxxxxxxx'
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@xxxxxxxxxxxx
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.
|
