|
Thanks for reporting Sebastiaan. You raise a good point regarding actual object vs proxy equality which becomes obvious when dealing with collections.
The solution here is to let hte proxies implement the equals and hashcode by delegating to the target object. In Spring DM we'll probably do this automatically for the user or we'll provide a specific interface that can be added to the proxies so they can be distinguished from 'normal' proxies. We'll probably add a flag to the schema so this can be turned off if not needed. I've raised the priority of the issue but I'm not sure at the moment what's the ETA... Thanks for looking in to it. :-)
I'm wondering about the solution though to let proxies implement equals and hashcode by delegating. Suppose you do proxy1.equals(proxy2). Then if proxy1.equals() delegates it will call delegate1.equals(proxy2), which will fail most of the time, because of the standard equals constructions which tests class equality (and delegate1.getClass() != proxy2.getClass()). Of course the equals method of the proxy could test if the argument is a known proxy (i.e., proxy2 instanceof the proxy1 class) and unwrap the delegate2 from it and use that in the delegated equals argument; this would of course only work if the same proxy class is always used but breaks as soon as there are 2 different eqhash delegating proxies for 1 class. How would this work in an OSGI setting where 1 bundle exports a spring service, and different importing bundles each create their own dynamic proxy around the service? That is, bundle "a" exports service "a", bundle "b" imports it and creates $Proxy1(a) and bundle "c" creates $Proxy2(a)? (This is really what happens; the bundles each create their own proxy and thus have a different proxy class). There are several comparisons that must work in the end, the hairier ones being: a.equals($Proxy1(a)) // this will only work if a is proxied as well, i.e., no bare a is exposed $Proxy1(a).equals($Proxy2(a)) I guess having the dynamic proxy implement not only the service interface but also a special interface which has a getDelegate() method that can be used to get the delegate for the equals method can solve this problem, as long no bare (non-proxied) "a" can occur (i.e., in bundle "a" the service "a" is also proxied). Of course this might cause double proxies $Proxy1($Proxy0(a)) (i.e., the proxied service "a" imported in bundle "b"), which would mean that getDelegate() needs to be recursive (and so getDelegate() turns out to be a bad name, getProxyTarget() may be better or something like that). Is something like this the solution you have mind? Regards, Sebastiaan Hi :-)
My point is servicing a DataSource is not a good way, in my project, I servicing a hibernate's SessionFactory. DataSource is usually leveraged by pooling, there are special mechanism for reclaiming objects. Good Luck In M2 this problem will be addressed by implementing InfrastructureProxy new in Spring 2.5.4. I have the code working locally but I'm waiting for a proper snapshot artifact to be deployed.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Juergen