axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rutger.lubb...@vodafone.com
Subject JAXB (de)serialization, how to get rid of the manual steps.
Date Mon, 21 Feb 2005 14:18:46 GMT
Hi,

In order to expose a "JAXB service" (see other mail about JAXB
(de)serialization, in the user list) there are a few steps one has to take.
These steps are, in short:
1) Generate a "SOAP service", this is actually the implementing class. 
2) Invoke Java2WSDL for this "SOAP service", generating a wsdl file;
3) Edit the wsdl file, insert the appropriate <wdsl:types> there;
4) Invoke WSDL2Java for this wsdl file, with '-H' and the implementing class
of step 1;
5) Delete axis generated beans, keeping  the *_Helper files.
6) Search the files for org.axis.encoding.ser.Bean and replace that into the
JAXB (de)serializers.

There are ofcourse also a few assumptions, these are:
- For a given businses object there are two java classes, the object itself
and a "Type" (eg Address implements AdderssType);
- For a given set of object and "Type"s there is one jaxb schema file (eg
Address.xsd), with an element of type "Type" (<xsd:element name="Address"
type="AddressType"/>);
- The schemas are available at compile time;

These steps with those assumptions work, now it's more or less time to make
all of this available in one ant task, or at least make the manual part of
step 3 obsolete.

As far as I understand it, in step 2 a wsdl file is generated. The
generation goes via a type mapping (registry), where for each type a
serializer is registered. This serializer in turn knows how to flatten the
pojo into a schema (string).

Now, for a given JAXB context (a package name), I could create a type
mapping that defines the mapping for all classes in that package. This
mapping then returns the correct (de)serializer(factories) for the JAXB
types. This makes step 3 obsolete. 

This might not be the best way to tackle this problem, suggestions are
welcome. But, if I'd continue in this way this leaves me with the following
questions:

1) where and how do I set the type mapping? 
2) how do I generate the schemas for the java types?

For step one I probably need to modify a few classes, so I could register
the type mapping (as a delegate mapping???), could someone please help me
here? For instance, add a few methods to set a type mapping, for instance
add them to the Java2WSDL.

For step two I could assume that when one uses JAXB generated classes one
has access to the schema files JAXB needs. If so, I could simply return the
schema from such a file. I don't know if this is desirable? 
Another idea would be to somhow modify the type descriptions at java2wsdl
time to get a "xsd:include" for each jaxb type. The rest of the description
(with _Helper files) then has to remain the same, otherwise we'de have to
distribute the schemas as well.
Another track could be to modify the BeanSerializer to handle this schema
creation. At the moment the BeanSerializer complains about no default
constructor being available, which could perhaps be bypassed. 

I think that perhaps getting something like the BeanSerializer working with
the JAXB classes is the way to go, so we don't have to bother (dependend)
projects with our JAXB definitions, they can simply use it then.

Any comments and thoughts welcome.


Cheers,


Rutger Lubbers

Mime
View raw message