Hello Martin,
Let me first summarize what I think you say your problem is. If I got it
wrong, no need to read the rest of this e-mail :)
You have POJOs generated by Hibernate. You want to have a method in your
web service that takes these POJOs as arguments, so that data can be
exchanged between the client and database with the least hassle.
However, after generating the WSDD and Java classes from the WSDL that
you generated from your interface, you notice that some Java types of
the fields in the Javabeans changed. Right?
First of all, the web service is a middle layer and I wonder whether it
is a good idea to expose classes that depend so much on your schema
directly to your clients. A little change to your DB schema would give
you a lot of maintenance.
As there are no XML types that map to java.util.Set, java.util.Date,
you'd either have to look at your schema or Hibernate to see if you
can't have your Hibernate generated POJOs use Java types that can be
mapped to, or write adapters. I'd go for the latter solution, as it has
the added advantage of separating the DB and client layers.
Good luck,
Dies
Martin Wunderlich wrote:
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
