On Oct 7, 2010, at 10:23 PM, Israel Lacerra wrote:
I think I really need initialize the command on
CommandsFactoryImpl.initializeReplicableCommand. In RemoteCommandsFactory we only
initialize the parameters that have been serialized.... right?
Well, not only, see StateTransferControlCommand:
case StateTransferControlCommand.COMMAND_ID:
command = new StateTransferControlCommand();
((StateTransferControlCommand) command).init(transport);
break;
However, it feels to me that any initialization happening in
RemoteCommandsFactory.fromStream() is for global, or cache manager level, components. On
the other hand, CommandsFactoryImpl.initializeReplicableCommand initializes commands based
on the specific target cache that the command interacts against.
I need a cache local instance... and RemoteCommandsFactory does not have it (at least not
yet).
At first glance, if you need the local cache instance,
CommandsFactoryImpl.initializeReplicableCommand might be the place. However, where does
this cache come from exactly?
An alternative would be for the cmd to be initialized with the cache manager (global
component) and cache name and you can derive the cache from there, couldn't you?
On Thu, Sep 30, 2010 at 9:58 PM, Israel Lacerra <israeldl(a)gmail.com> wrote:
On Thu, Sep 30, 2010 at 8:15 PM, Manik Surtani <manik(a)jboss.org> wrote:
On 30 Sep 2010, at 23: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?
Yes, if your custom command is not visitable then you won't need to extend Visitor,
etc.
> 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?
This is in the RemoteCommandsFactory right? This is why I suggested
RemoteCommandsFactory.fromStream() has a Map which contains IDs mapped to a command
creator instance. A command creator could be an interface that looks like:
No. This is in the CommandsFactoryImpl.initializeReplicableCommand. But maybe it could be
on RemoteCommandsFactory. I did not remember if JavaDoc made me put this on
CommandsFactoryImpl or if I really tried on RemoteCommandsFactory and did not worked.
interface CommandCreator<C extends ReplicableCommand> {
C createAndInitialize();
}
So when you register a new command ID you also create and register a new CommandCreator
instance which knows how to create and initialize the command.
I'll try and find some time tomorrow to hack up a hypothetical example. Should make
it clearer for everyone.
More comments? Mircea, Sanne?
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache