Stephen, Great stuff. I'd rather check for whether a class in question implememts an interface than implement a string matching algorhythm. Can you please create a new issue (has one already be created; cannot remember .. ;-)), and attach this your findings to it.
Thanks Werner > -----Original Message----- > From: Stephen Bash [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 07. März 2006 14:19 > To: [email protected] > Subject: Re: [castor-user] Problems marshalling a proxied class > > Gentlemen- > > Since this has been bugging me, I did some searching on the > CGLIB mailing list and here is the result: > > http://sourceforge.net/mailarchive/message.php?msg_id=9827333 > > I don't know any of the players over there, but from what > little reading I did, the author of the above message, Chris, > seems to be authoritative on the codebase. His suggestion is > to test whether a class implements the > net.sf.cglib.proxy.Factory interface in order to identify > proxy objects. This is probably slightly better than string > matching, but I'll leave it up to others to determine how much better. > > Thanks, > Stephen > > > > > On 3/5/06, Werner Guttmann <[EMAIL PROTECTED]> wrote: > > Ralf, > > > > that just reminds me that this is not only related to > Hibernate, but > > to Castor JDO as well, as we are using CGLIB to create > proxies for 1:1 > > relations that are flagged as lazy-loaded. > > > > Testing for the term CGLIB in a class name does not appear > to me like > > an ideal solution, but I cannot think about any other way > to go about > > this problem. > > > > Regards > > Werner > > > > Ralf Joachim wrote: > > > Hi Stephen, > > > > > > that CGLIB stuff is a bit tricky. Maybe I can give soem > informations > > > that can help you to find a solution. > > > > > > If you create a CGLIB-Proxy for class A, the proxy will behave as > > > being of a class that extends A and may also implement some > > > additional interfaces. There for if 'proxy is the > CGLIB-Proxy of class A you get: > > > > > > assertTrue(proxy instanceof A); > > > assertTrue(proxy.getClass() != A.class); > > > > assertTrue(proxy.getClass().getName().equals("A$$ProxiedByCGLIB")); > > > // (not sure on the extension of A but it includs '$$' > and 'CGLIB') > > > assertTrue(proxy.getClass().getSuperClass() == A.class); > > > > > > Depending on the construction of the proxy, the following > may also > > > be > > > valid: > > > > > > assertTrue(proxy instanceof AnAdditionalInterface); > assertFalse(new > > > A() instanceof AnAdditionalInterface); > > > > > > The proxy itself behaves similar to > java.lang.reflect.InvocationHandler. > > > Each method call is passed to an invoce method where the > > > implementer of the proxy can define the behaviour of the > proxy. In > > > most cases the proxy will add some additional > functionality to the > > > original class. At hibernate I expect that on every > invocation of a > > > method of A, the proxy will load the required object and call the > > > same method on it. For internal use I also expect hibernate to > > > implement an interface that offers additional methods. > > > > > > The problem that Paul has, and others had before, is that Castor > > > calls > > > getClass().getName() on every object it have to marshal. As this > > > call does not return the name of the original calls but > the one of > > > the proxy (e.g. A$$ProxiedByCGLIB) Castor is not able to find the > > > right mapping and uses intorspection instead. Introspection also > > > finds the hidden interface methods and tries to marshal > their result. > > > > > > The only 2 solution I can see are: > > > > > > 1. test for the hidden interfaces with instanceof. as this would > > > require us to rever to a class of hibernate I'll refuse that. > > > > > > 2. test if getClass().getName() includes 'CGLIB'. if that's true > > > call > > > getClass().getSuperClass().getName() instead and use this one to > > > search for a mapping. > > > > > > Just my 0,02 cent or maybe a bit more ;-) > > > > > > Regards > > > Ralf > > > > > > > > > > > > Stephen Bash schrieb: > > >> Paul- > > >> > > >> I've been pondering your problem on and off most of the day. > > >> Recently someone else had a different problem also > related to the > > >> CGLIB proxies, so there may be some merit in looking into them. > > >> > > >> Just to make sure I understand the problem, the proxy > classes have > > >> extra get methods that return objects you don't want to > marshal? > > >> And since Castor validates the mapping file against the real > > >> classes, not the proxy classes, marking the "field" as transient > > >> causes a MappingException? > > >> > > >> I'll try to think about it a little and see if we can > find a simple > > >> solution. > > >> > > >> Stephen > > >> > > >> > > >> On 3/2/06, Paul Grillo <[EMAIL PROTECTED]> wrote: > > >> > > >>> I have a nasty problem. Been using Castor for a couple > of years > > >>> for all our classes. Basically we have a large set of mapping > > >>> files that generally use auto-complete="true" and we > specify what > > >>> is transient. > > >>> > > >>> We are now implementing Hibernate to perist. However, when we > > >>> load up an object from the DB and then go to marshal it > we see the > > >>> following problem. > > >>> > > >>> Hibernate uses CGLIB and proxies for the class. At run > time there > > >>> is a "getxxxx" that returns an object that we definately do not > > >>> want to marshal. > > >>> > > >>> So, i can'd set it transient because Castor complains that it > > >>> cannot find it in the unproxied/mapped class. > > >>> > > >>> It will be a large problem for us to crawl through all > our mapping > > >>> files and specify each attribute for mapping. Is there a way > > >>> around this? > > >>> > > >>> Are there any hooks in Castor where i can indicate to it to not > > >>> marshal a particular attribute? Any code i can inject > any where > > >>> to handle this? > > >>> > > >>> thanks. > > >>> > > >>> oh, the decision to use Hibernate has been made. Not > sure i can > > >>> switch to anything else at this point. > > >> > > >> > > > > > > ------------------------------------------------- > > > If you wish to unsubscribe from this list, please send an > empty message > > > to the following address: > > > > > > [EMAIL PROTECTED] > > > ------------------------------------------------- > > > > > > > > > > > > ------------------------------------------------- > > If you wish to unsubscribe from this list, please > > send an empty message to the following address: > > > > [EMAIL PROTECTED] > > ------------------------------------------------- > > > > > ------------------------------------------------- If you wish to unsubscribe from this list, please send an empty message to the following address: [EMAIL PROTECTED] -------------------------------------------------
