In general, with JAXB 2.1, the classnames and package structure is irrelevant as long as all the annotations are completely correct and appropriate package-info.java files are stuck in the packages.

Basically, the procedure would be:

1) generate the "default" code
2) copy/update the generated package-info.java into all you packages. The annotations in there define the namespaces and the qualifications and such. 3) Copy the annotations out of all the generated classes into your equivilent classes. The annotations should exactly match.

Once you have your classes all "working", you can create a jaxb bindings file that would be passed to wsdl2java to tell it to map the types to your classes. Sample at:
http://svn.apache.org/repos/asf/cxf/trunk/common/schemas/src/main/resources/schemas/wsdl/wsdl.xjb
It's kind of a pain though if you have a lot of them. You need an xpath to each class. You CAN embed the jaxb binding directly into the xsd:annotation things in the schema if you want to avoid that, but that kind of pollutes the schema.

Dan




On Jul 2, 2008, at 2:30 PM, Kugaprakash Visagamani wrote:

Hi Daniel,

Greatly appreciate your response and Thank you for the suggestion.



I have actually copied the JAXB annotations from the WSDL generated java classes to my Beans object. Can you help me with little more information as to how can I customize my converted bean (jaxb) to map to the schema?



Sample of my Converted Jaxb object:



Package stu.xyz

@ @XmlAccessorType(XmlAccessType.FIELD)

@XmlType(name = "Child", propOrder = {

   "address"})

Public class Child extends Parent{

     @XmlElement(name = "mac_address")

     Private String address;

     .....

}



But the WSDL generated object looks like:



Package abc.def

@ @XmlAccessorType(XmlAccessType.FIELD)

@XmlType(name = "TempChild", propOrder = {

   "address"})

Public class TempChild extends TempParent{

     @XmlElement(name = "mac_address")

     Private String address;

     .....

}



Can you please help me as to how and where do I map in the WSDL to
unmarshall to my jaxb converted "Child".

Note that the package structure is also different.

Please help me with any suggestions.

Thanks

Kuga





-----Original Message-----
From: Daniel Kulp [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 02, 2008 7:46 AM
To: [email protected]
Subject: Re: Using existing Java objects as against the WSDL generated
java objects!





Without knowing complete details of what the "differences" are, this

is a very hard question to answer.



If your beans "look" like the jaxb beans, but with additional business

logic methods added, it's fairly straight forward.   You can pretty

much copy the JAXB annotations over to your beans and just use your

beans.   With jaxb, you can even add extra methods that are called

after the data is read to finish any extra wiring you need done.



If you get it so your objects are usable with JAXB, you can use jaxb

customizations at code generation time to tell it to map the schema

types into your objects instead of code generating new objects.    You

can actually do this piece meal.   Map the objects you have working

and code generate the rest.



Dan







On Jun 26, 2008, at 2:21 AM, Kuga wrote:





Hi,

We have several existing Java POJO classes in client side.

Now we are planning to use the WSDL, as such we have defined the WSDL

definition, based on server side schema, and then generated Java

objects. I

would not be able to just use these generated classes in the client

side

instead of my POJO, as some of the POJO has some business logic also

involved in them.



As such can I use my POJO instead of the WSDL generated Java

objects. Where

do we need to add these mappings in the WSDL file.



Any help is appreciated.

Thanks & Regards

Kuga

--

View this message in context:
http://www.nabble.com/Using-existing-Java-objects-as-against-the-WSDL-ge
nerated-java-objects%21-tp18127291p18127291.html

Sent from the cxf-user mailing list archive at Nabble.com.





---

Daniel Kulp

[EMAIL PROTECTED]

http://www.dankulp.com/blog










---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog




Reply via email to