> > There are several points to consider with this, and I am > going to try > > to hit them all (in no particular order) > > > > 1) What are the downsides to doing this? If the goal is > give a drop-in > > replacement to the JDK-generated proxies based on > interfaces, then none. > > if this feature is planned for 1.0.x we should introduce as > less incompatibilities as possible. I agree completely. I think the plan of a drop-in replacement that is invisable to the user for 1.0.X line and a configurable strategy for 1.X is wise. I could see waiting for 1.1 to introduce any of this, but the timeline for that is so unknown, and I think this could be useful in the immediate future. > is it really necessary to define the proxy-generator on > class-descriptor level ? what's the benefit of having a > bytecode proxy on one class and a jdk-proxy on the other > class. imo we could define a global proxy-generator to > generate the proxies for classes with proxy='dynamic' > and for classes with proxy = 'myclass' it's up to the user. > I agree completely, and eventually worked myself to that way. My current implementation of this only uses CGLIB to generate proxies. JDK proxies are no longer used. There are no new configuration settings. Setting either 'dynamic' at the ClassDescriptor, or 'proxy=true' at the ReferenceDescriptor generates a CGLIB-backed Proxy based on the itemClass, regardless of what interfaces it implements (since the new proxy is guaranteed to implement them all since it is a subclass of the itemClass). Thanks for all the feedback! I really do appreciate it. My hope is to have something done for the 1.0.X line by early next week that can be reviewed, and then I will start work on design for the 1.X lines pluggable model. -Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
