I was hoping you'd show me code, but I think I understand your situation.
What you call data-holders I call beans or, more appropriately, type
classes (things generated from the <types> clause in the WSDL).  You want
to have the non-bean aspects of these classes available on the client.
You're doing something out of the ordinary.  The normal scenario is that a
client is given WSDL and nothing else.  I don't want to simply add a
-noOverwrite flag because it's an all-or-nothing flag, either overwrite
everything (default) or overwrite nothing.  That's not what you want and
it's dangerous, you could end up with stale code if the WSDL changes (or if
WSDL2Java itself changes which, at this point in the life of AXIS is fairly
often).  I don't want to add a -noOverwriteTypeClasses either for the same
reason.  An alternative is:  "-noOverwrite <className>" but this would be a
nuisance if you've got dozens of classes you want to preserve.

You might be better served to write a simple script:

java org.apache.axis.wsdl.WSDL2Java <wsdlFile>
copy savedStuff/* .
javac *.java

We actually do this ourselves in a couple of our tests.  For example,
test/wsdl/sequence.

Russell Butek
[EMAIL PROTECTED]


Bob Cotton <[EMAIL PROTECTED]>@synxis.com on 03/06/2002 05:43:57 PM

Please respond to [EMAIL PROTECTED]

Sent by:    [EMAIL PROTECTED]


To:    [EMAIL PROTECTED]
cc:
Subject:    Re: WSDL2Java data-holder generation (or not)



>>>>> "Russell" == Russell Butek <[EMAIL PROTECTED]> writes:

    Russell> Could you show me a concrete example of what you desire
    Russell> so I can be sure I understand what you're asking for?
    Russell> What sort of functionality are you losing?  It shouldn't
    Russell> matter what the server-side vs client-side code looks
    Russell> like as long as the SOAP messages sent back-and-forth are
    Russell> understood.

I have some data-holder classes that the service uses to return data
to client. These data-holders have the full complement of getters and
setters so they can be passed through the BeanSerializer. They also
home some other functionality such as toString(), for example, that
returns the bean's getName() method. We would like to preserve this
behavior on the client side.

    Russell> The WSDL2Java option would probably be rather complex.
    Russell> Since it doesn't know about the existing server-side
    Russell> classes, you'd have to give it lots of information to
    Russell> find those classes.

Currently Java2WSDL, if not supplied with any package->NS mapping will
provide its own:

          <schema targetNamespace="
          http://va.cdo.webservices.srms.synxis.com"; xmlns="
          http://www.w3.org/2001/XMLSchema";>


With this present, WSDL2Java will use the above namespace to generate
a data-holder into com.synxis.srms.webservices.cdo.va. (The exact
place that the data-holders currently live) and my classes will be
overwritten.

The generated deploy.wsdd has the right package names for the
beanMappings. So I delete the generated data-holders, and use my
original (on both sides) and all is good.

Because we control both sides of the app, I would like to use our
existing data-holders.

All I want is an option to suppress the generation of the
data-holders. Leave everything else as it is.

- Bob

    Russell> Bob Cotton <[EMAIL PROTECTED]>@synxis.com on 03/06/2002
    Russell> 03:27:06 PM

    Russell> Please respond to [EMAIL PROTECTED]

    Russell> Sent by: [EMAIL PROTECTED]


    Russell> To: [EMAIL PROTECTED] cc: Subject: WSDL2Java
    Russell> data-holder generation (or not)




    Russell> It seems with axis, when doing Java <-> Java development
    Russell> the easiest thing is to use Java2WSDL then WSDL2Java to
    Russell> get your client stubs.

    Russell> If I have access to the same data-holder classes on both
    Russell> sides, it seems I loose functionality that may be in my
    Russell> Bean classes on the server-side when I generate the
    Russell> client-side data-holders.

    Russell> Would it be possible to add a switch to WSDL2Java to NOT
    Russell> generate the data-holders and instead use the
    Russell> "server-side" classes?

    Russell> Thanks

    Russell> - Bob


    Russell> -- SynXis Corporation | [EMAIL PROTECTED] | Obstacles are
    Russell> those frightful 1610 Wynkoop, Suite 400 | Ph:
    Russell> (303)595-2511 | things you see when you take your Denver,
    Russell> CO 80202 | Fax:(303)534-4257 | eyes off your goal.
    Russell> -Henry Ford



--
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



Reply via email to