I think your approach is very valid in the context of Castor's current limitations. Refactoring your second approach to use (Spring) AOP to avoid any intrusiveness on your domain objects sounds like a very valid approach to me.
On the other hand, I think what Ralf is suggesting is that is is possible to amend Castor's internal code so that we can deal with lazy-loaded domain objects where the solution has been achieved using CGLIB. Werner > -----Ursprüngliche Nachricht----- > Von: Developer Dude [mailto:[EMAIL PROTECTED] > Gesendet: Mittwoch, 07. März 2007 21:41 > An: [email protected] > Betreff: RE: [castor-user] Marshalling Hibernate Proxy objects with Castor > > Thanks Ralf. > > My response was meant more as pointer to a workaround that I am not even > sure is applicable to the thread (I didn't look at the discussions > mentioned > - it just sounded kind of like what I dealt with). Right now we have a > framework that works, and I think in the future we are looking at Xfire > for > our SOAP transactions, but I am not involved with that right now so I have > no idea how that will affect our Castor bindings. > > -----Original Message----- > From: Ralf Joachim [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 07, 2007 12:24 PM > To: [email protected] > Subject: Re: [castor-user] Marshalling Hibernate Proxy objects with Castor > > 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 > > > > --------------------------------------------------------------------- > 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
