On Fri, Jul 16, 2010 at 3:20 PM, Matt Benson <[email protected]> wrote: > * 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... >
The code is just sitting there until I "move" it. Right now, it's duplicate code, because I copied it over to the submodule when I created it, but eventually, the top-level module will just be a "pom" module (probably renamed to commons-proxy-parent) and it will contain no code. > * 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. > So, do you propose having something like this: public <T> T createDelegatorProxy(ObjectProvider<T> delegateProvider,Class<T> mainClass, Class<?>... otherClasses ); I guess I wouldn't mind this, because folks are most likely going to want to use the proxy when they create it if they've got a "mainClass" in mind (have the other array-based method for those that don't perhaps). I really like the varargs ability. It makes creating proxies that support multiple interfaces very easy: MyBusinessInterface obj = proxyFactory.createDelegatorProxy(provider, MyBusinessInterface.class, Serializable.class); Otherwise, I've got to create the array myself and that's not as readable. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
