You can use xs:dateTime with java.util.Calendar - its pretty easy to get from there to java.util.Date . Some databinding frameworks - JWSDP for example - support java.util.Date directly.
The way I use Hibernate collections is to map them to Arrays. WSDL handles array well. java.util.List and java.util.Set works well in that regard directly via Collection.toArray() . For java.util.Map, I create a complex type that has an array each of the keys and values, and then just compare the size to make sure they're equal.
For Hibernate based POJO's with lots of fields - you need to map one to one the POJO to a complex object. I typically do this in an Adapter.
HTH,
Robert
http://www.braziloutsource.com/
On 4/19/06, Dies Koper <[EMAIL PROTECTED]
> wrote:
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
