On 30 Sep 2010, at 22:48, Israel Lacerra wrote:
On Wed, Sep 29, 2010 at 4:06 PM, Manik Surtani <manik(a)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):
good point; actually that's why VisitableCommand is an
ReplicableCommand: not all replicable commands need the go through the interceptor store.
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 pass in the ComponentRegistry which contains pretty much all.
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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev