On Jul 14, 2010, at 9:21 PM, James Carman wrote:

> All,
> 
> One of the biggest complaints I've received from folks about the proxy
> library is that it's not based on interfaces.  The main class is the
> ProxyFactory class and it's a concrete class which implements all
> proxying logic using JDK proxies.  We did this for maintainability
> (adding stuff to the interface breaks binary compatibility as opposed
> to adding a method to a concrete superclass with an implementation).
> I would like to re-structure proxy so that it contains a few
> modules...
> 
> 1.  Commons Proxy Core - the API itself containing the ProxyFactory 
> *interface*
> 2.  Commons Proxy JDK - the JDK proxies implementation
> 3.  Commons Proxy CGLIB - the CGLIB implementation
> 4.  Commons Proxy Javassist - the Javassist Library
> 
> With the new paradigm of just bumping major version numbers (and
> package names) allowing us to break compatibility, I don't think the
> interface issue is that much of an issue anymore.  What do you guys
> think?

Okay, now that we have some code to talk about, we can start banging stuff out. 
 :)

* WRT modules, what do you intend for the code remaining in the parent project? 
 I thought we might have a module each where we provide specialized 
implementations of Invoker|Interceptor|ObjectProvider...

* Regarding ProxyFactory's new convenience methods, what would you think about 
changing the interface such that the single-class method and the varargs method 
are merged, and the original Class[] argument type is restored for the other 
methods?  This would emphasize the fact that creating a proxy of *no* 
classes/interfaces makes no sense, as well as provide a means of returning a 
strongly-typed result even when multiple interfaces are specified.

-Matt

> 
> Thanks,
> 
> James
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to