[infinispan-dev] Defining new commands in modules

[Israel Lacerra]

On Thu, Sep 30, 2010 at 8:15 PM, Manik Surtani <manik at 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 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?
>
>
> 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 at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100930/bde91384/attachment.html