I am not very experienced with Hibernate, mostly being a client side guy, but I have run into this issue. I have seen two approaches to the lazy mapping problem, both similar:
1) Two different classes for the same POJO, one a Hibernate object, the other a plain POJO object. One POJO is mapped to Hibernate and is more or less geared towards how the values are persisted in the DB, the other is the business object that the client uses and is what is sent back and forth via SOAP/Castor. The mapping logic between the two objects has caused no end of bugs, is hard to understand and just a plain mess IMO (mostly the result of outsourcing the server code at one time in the past and we now live with that legacy) - not to mention the fact that there are two classes to maintain for each POJO abstraction. 2) A similar approach but with a much simpler in house server project I became responsible for (after it was already written). The objects mapped one to one for the most part, and the objects themselves have mapping methods and copy constructors to go back and forth. I changed one of these classes to be the same class that both server and client to use. One of the problems I found with the class was that its parent class was package level private, and Castor could not see its constructor. Once I fixed that it was fine - except for the lazy population that Hibernate does. I found that if, just before the server side sends the object back to the client via SOAP/Castor, I use a copy constructor or mapping method to create a new instance of the object, one that wasn't created via Hibernate, then I get a fully populated object that Castor can work with. I now need to go and change all the other classes to use the same approach so we don't have two classes to maintain. I think that using some sort of AOP approach, such as Spring, one could maybe avoid building the mapping method/copy constructor into the POJO. That is my brute force simplistic approach to the problem. That too may cause performance issues, but at some point Hibernate needs to fully populate the object if you are going to marshal it with Castor. The way I did it the populating by Hibernate doesn't happen until I am ready to marshal, so no unnecessary population happens and I think that is the best you can ask for. -----Original Message----- From: Werner Guttmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 07, 2007 10:19 AM To: [email protected] Subject: Re: [castor-user] Marshalling Hibernate Proxy objects with Castor No, it hasn't. But there's a Jira issue that deals with this (same) problem. I hope we'll find some time soon to address this. But as always, there's only limited time available for us committers, as most of us have to accommodate professional as well as private life as well. Werner Urso Wieske wrote: > Hi > > > > I noticed the discussions about the problems with marshalling > Hibernate proxy objects with Castor. > > I have the same problem. > > I have defined my POJOs as lazy (proxy) in Hibernate. > > When Castor tries to marshal them, I would get exceptions > (SQLexceptions in combination with Castor XML field handler implementation classes). > > > > I decided to to make sure that all fields were supplied with the > set-method attribute of castor. I also set the class attribute > auto-complete to false to prevent Castor from introspecting the objects. > > > > But it did not work. > > In order to go around this problem, I had to change my Hibernate class > mappings. I disabled lazy/proying on the classes. > > But of course nrate Castor from introspecting the objects. > > , now I have a serious performance issue. > > > > I wondering: "Has this problem alreadya serious performance issue. > > been solved in CASTOR 1.1 ? (I am using version 1.0.5 of CASTOR.) > > > > Kind Regards > > Urso Wieske > > > > > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.5.446 / Virus Database: 268.18.7/712 - Release Date: > 6-3-2007 > 15:42 > --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
