On 29 May 2008, at 14:43, Mircea Markus wrote:
Manik Surtani wrote:
> Looks good. A couple of implementation notes:
>
> 1. ReplicationListener constructor - getting components from the
> cache
>
> TestingUtil.extractField() is brittle (since it relies on field
> name) and could break with even the slightest refactoring. Better
> to use TestingUtil.extractComponentRegistry() and
> ComponentRegistry.getComponent() to get the component you want.
> Much safer.
>
Fair point. It's not that I've even though about this nice
solution :) , but in this scenario it just doesn't apply because
rpcDispatcher in RPCmanagerImpl is build using 'new', not through
dependency injection and it is not even registered in the component
registry.
> 2. ReplicationListener constructor - updating components in the
> cache
>
> Again rather than using TestingUtil.replaceField() - equally
> brittle - try using componentRegistry.registerComponent() to
> register a new component, and componentRegistry.rewire() if the
> cache is already running to ensure the new component is re-injected
> everywhere it is needed.
>
same reason as bellow, the marshaller is not injected.
Surely these components can be added to the ComponentRegistry? We'd
need a RpcDispatcherFactory, with knowledge of how to build the
necessary RpcDispatcher, have that injected into the RpcManager. We'd
also need a ChannelFactory and register the Channel as a component,
and declare it as a dependency of our RpcDispatcher implementation.
Waitaminit, this won't work. JGroups' RpcDispatcher, which we extend,
doesn't expose a no-arg constructor. Damn. Bela, Vladimir: any
chance of introducing a no-arg constructor for the RpcDispatcher?
Surely others who have tried to use the RpcDispatcher from Spring,
etc. would have had similar issues as well?
Cheers
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org