[infinispan-dev] Defining new commands in modules

[Israel Lacerra]

On Wed, Sep 29, 2010 at 4:06 PM, Manik Surtani <manik at jboss.org> wrote:

> So this is an extension to the discussion around a GenericCommand that has
> been going around.  IMO a GenericCommand is a big -1 from me for various
> reasons - the whole purpose of the command pattern is so we have strongly
> typed and unit testable commands.  This will help the ongoing work by
> Mircea, Sanne and Israel on various modules that need to define custom
> commands.
>
> I proposed the following solution to Mircea earlier today, I'll repeat here
> for you guys to discuss.  Note that this is a *half baked* solution and
> needs more thought!  :-)
>
> * If a module needs to define custom commands, it should define its own
> ReplicableCommand implementations in its' own module.
> * It should define a sub-interface to Visitor (MyModuleVisitor) with
> additional methods to handle the new commands
> * Interceptors defined in this module should extend CommandInterceptor AND
> implement MyModuleVisitor
> * These new commands can be created directly, or via a new CommandFactory
> specially for these commands.
>
> Just to make clear what is my problem... The ReplicableCommand does not
need to be necessarily a VisitableCommand, right? In my case it's a
CacheRpcCommand and I have to initialize this on
CommandsFactoryImpl.initializeReplicableCommand(ReplicableCommand, boolean):

case ClusteredQueryFacade.COMMAND_ID:
             ClusteredQueryFacade csc = (ClusteredQueryFacade) c;
             csc.initialize(cache);
             break;

The problem is each ReplicableCommand may have a different way to
initialize. Maybe we can create a big initialize method, that receives a lot
of arguments, and the command uses just some of them. Or this problem will
de solved with the solution that you proposed?

Or maybe there is a better way to initialize the CacheRpcCommand... and I
choose the wrong way.


cheers
Israel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100930/2647b084/attachment.html