[jbosscache-dev] Re: new utility classes for removing Thread.sleeps

[Manik Surtani]

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 at jboss.org