Hello Vartan,

Thank you very much for your help and your suggestion.

In the meantime, I seem to have identified the root cause of my
problems and it seems to be on a conceptual level rather than a coding
level. Taking a closer a look at the classes generated by WSDL2Java I
noticed that the utility will also produce its own versions of any
objects (POJOs) that serve as complex type arguments. A number of
important changes are made there: final static constants are removed,
(de)serializers are added, java.util.Date get converted to Calendar
type, Sets are converted to object arrays.

This
is worsened by the fact that I am using Hibernate for the persistence
of these objects and they were auto-generated from the database. I am
a bit lost now how to deal with this situation. It seems that I have
to create and maintain two versions of the same object type, one for
the web service and one for the persistence layer or perhaps work with
some sort of adapter class, thereby tripling all the efforts. Seems like too 
much
maintenance hassle than I would want to deal with.

Are there any
established best practices for how to deal with such a situation?

Cheers,

Martin

> Hello Martin,

> Apologies in advance if the comment below is not addressing the
> right question....


> I had to set a serializer and deserializer when passing a complex
> type or when expecting a complex type as a return value from a call.

> I did something like this on my call object:
>         QName classQName = new QName("http://my.namespace";, "Foo");
>         Class cl = Foo.class; 

>         BeanSerializerFactory bsf = 
>             new BeanSerializerFactory(cl, classQName);
>         BeanDeserializerFactory bdf = 
>             new BeanDeserializerFactory(cl, classQName);

>         call.registerTypeMapping(cl, classQName, bsf, bdf);

> This was for expecting a Java Bean as a return value.  I saw a
> section about complex types that are not Java beans in the AXIS
> user's guide.  Look at the section "Encoding your Beans - the
> Bean Serializer".  Also see the section below it:
> "When Beans Are Not Enough - Custom Serialization".


Reply via email to