You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by Naresh Bhatia <NB...@sapient.com> on 2002/05/13 16:25:23 UTC

Java classes generated by WSDL2Java

I have some questions regarding the Java classes generated by WSDL2Java. My
assumption is that WSDL2Java was written primarily to create a Web Service
client. However it is making the maintenance of my business data classes a
bit awkward. Let me try to explain...

When I use Java2WSDL followed by WSDL2Java, the classes generated for these
types are different from the original Java classes - they have some
additional methods (such as equals(), hashCode(), getSerializer(),
getDeserializer() etc.) and some methods removed.

1) Does WSDL2Java make any attempt to merge the methods into the original
classes? 

2) What is the recommended approach to keep one copy of data classes for the
client and the server?

3) The getSerializer() and getDeserializer() methods make the data classes
SOAP specific. Is there a way to take these methods out of the data classes
in order to keep them generic and not tied to SOAP?

If there is a more elegant approach to solving this problem, I would like to
hear about it.

Thanks.

Naresh Bhatia


Re: Java classes generated by WSDL2Java

Posted by Bob Cotton <bc...@synxis.com>.
>>>>> "Naresh" == Naresh Bhatia <NB...@sapient.com> writes:

    Naresh> I have some questions regarding the Java classes generated
    Naresh> by WSDL2Java. My assumption is that WSDL2Java was written
    Naresh> primarily to create a Web Service client. However it is
    Naresh> making the maintenance of my business data classes a bit
    Naresh> awkward. Let me try to explain...

    Naresh> When I use Java2WSDL followed by WSDL2Java, the classes
    Naresh> generated for these types are different from the original
    Naresh> Java classes - they have some additional methods (such as
    Naresh> equals(), hashCode(), getSerializer(), getDeserializer()
    Naresh> etc.) and some methods removed.

    Naresh> 1) Does WSDL2Java make any attempt to merge the methods
    Naresh>    into the original classes?

    Naresh> 2) What is the recommended approach to keep one copy of
    Naresh>    data classes for the client and the server?

My approach has been to throw away the Axis generated type classes.
To do this I tell WSDL2Java to generate into a temp dir, then copy out
the files that I want (stubs etc)

- Bob
-- 
SynXis Corporation      | bob@synxis.com    | 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


Re: Java classes generated by WSDL2Java

Posted by Reddy <ec...@yahoo.ca>.
Hi all
I had the same problem, along with these two
additional ones
1) The object I ma using is a complex object and one
variable in the complex object is an object itself,
which has 12 Boolean fields, the wsdl type mapping is
missing all 12 elements from the wsdl:type definition.
2) The schema for my object generated by Java2wsdl is
missing some attributes.

IF any one has a workaround can you guys suggest me?

Thanks
Reddy
--- Naresh Bhatia <NB...@sapient.com> wrote:
> I have some questions regarding the Java classes
> generated by WSDL2Java. My
> assumption is that WSDL2Java was written primarily
> to create a Web Service
> client. However it is making the maintenance of my
> business data classes a
> bit awkward. Let me try to explain...
> 
> When I use Java2WSDL followed by WSDL2Java, the
> classes generated for these
> types are different from the original Java classes -
> they have some
> additional methods (such as equals(), hashCode(),
> getSerializer(),
> getDeserializer() etc.) and some methods removed.
> 
> 1) Does WSDL2Java make any attempt to merge the
> methods into the original
> classes? 
> 
> 2) What is the recommended approach to keep one copy
> of data classes for the
> client and the server?
> 
> 3) The getSerializer() and getDeserializer() methods
> make the data classes
> SOAP specific. Is there a way to take these methods
> out of the data classes
> in order to keep them generic and not tied to SOAP?
> 
> If there is a more elegant approach to solving this
> problem, I would like to
> hear about it.
> 
> Thanks.
> 
> Naresh Bhatia
> 
> 


______________________________________________________________________ 
Games, Movies, Music & Sports! http://entertainment.yahoo.ca