Russell,
I think that it would be reasonable to have a no overwrite option.
So prior to writing out a .java class for a type, the emitter could look
for an existing class in the class path or existing .java file.
This is done for the impl class, and this is simply and extension of that
functionality since the type class could contain implementation code.
Rich Scheuerle
XML & Web Services Development
512-838-5115 (IBM TL 678-5115)
Russell
Butek/Austin/IBM@ To: [EMAIL PROTECTED]
IBMUS cc:
Subject: Re: WSDL2Java data-holder
generation (or not)
03/06/2002 04:41
PM
Please respond to
axis-user
Could you show me a concrete example of what you desire so I can be sure I
understand what you're asking for? What sort of functionality are you
losing? It shouldn't matter what the server-side vs client-side code looks
like as long as the SOAP messages sent back-and-forth are understood.
The WSDL2Java option would probably be rather complex. Since it doesn't
know about the existing server-side classes, you'd have to give it lots of
information to find those classes.
Russell Butek
[EMAIL PROTECTED]
Bob Cotton <[EMAIL PROTECTED]>@synxis.com on 03/06/2002 03:27:06 PM
Please respond to [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: WSDL2Java data-holder generation (or not)
It seems with axis, when doing Java <-> Java development the easiest
thing is to use Java2WSDL then WSDL2Java to get your client stubs.
If I have access to the same data-holder classes on both sides, it
seems I loose functionality that may be in my Bean classes on the
server-side when I generate the client-side data-holders.
Would it be possible to add a switch to WSDL2Java to NOT generate the
data-holders and instead use the "server-side" classes?
Thanks
- Bob
--
SynXis Corporation | [EMAIL PROTECTED] | Obstacles are those frightful
1610 Wynkoop, Suite 400 | Ph: (303)595-2511 | things you see when you take
your
Denver, CO 80202 | Fax:(303)534-4257 | eyes off your goal. -Henry
Ford
