Hi Dude,
The easiest solution would be to take a peek at Castor marshalling code
when Castor searches for the ClassDescriptor. If the class of the object
to be marshalled implements a cglib interface then it needs to be
treated special. Instead of searching the ClassDescriptor for the class
wrapped by cglib you need to search the ClassDescriptor of its superclass.
If you'd provide us with a patch that fixes the problem we would be more
then willing to integrate that asap.
Regards
Ralf
Developer Dude schrieb:
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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
