[infinispan-dev] Defining new commands in modules

[Israel Lacerra]

I think I really need initialize the command on
CommandsFactoryImpl.initializeReplicableCommand. In RemoteCommandsFactory we
only initialize the parameters that have been serialized.... right?

I need a cache local instance... and RemoteCommandsFactory does not have it
(at least not yet).

On Thu, Sep 30, 2010 at 9:58 PM, Israel Lacerra <israeldl at gmail.com> wrote:

>
>
> 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/20101007/0b84fa70/attachment.html