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):
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