Probably a wiki, but definitely should be in the javadoc.
Essentially, if you plan for the command to be passed up the interceptor chain, make it
Visitable. Otherwise, a simple ReplicableCommand is fine if all you want is RPC.
On 7 Mar 2011, at 11:03, Galder ZamarreƱo wrote:
Looks nice and clean. As a SPI developer, it might be interesting to
understand better the difference between visitable and nonvisitable commands and when to
use which?
This kind of info could be embedded in the javadoc of
http://goo.gl/OkvU4 or
http://goo.gl/isR00 respectively? Or do you plan to write a wiki at some point?
On Mar 5, 2011, at 3:32 AM, Manik Surtani wrote:
> I know it's been a while since we spoke about this, but I now have a (working)
prototype of this work.
>
> Changes to Infinispan core to accommodate this:
>
>
https://github.com/maniksurtani/infinispan/commit/a6085647f2ac908d9307c9c...
>
> Sample module making use of custom commands (both visitable and not) as well as
custom interceptors:
>
>
https://github.com/infinispan/infinispan-sample-module
>
> Enjoy!
> Manik
>
> On 29 Sep 2010, at 21:06, Manik Surtani 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.
>>
>> Now for the un-finished bits. :)
>>
>> * How does RemoteCommandFactory instantiate these new commands? The module
should have a way of registering additional command IDs with
RemoteCommandFactory.fromStream(). See
>>
>>
http://fisheye.jboss.org/browse/Infinispan/branches/4.2.x/core/src/main/j...
>>
>> Perhaps RemoteCommandFactory.fromStream() should look up the ID in a map of
command creator instances, and each module can register more of these with the
RemoteCommandFactory?
>>
>> * How do interceptors defined in the core module handle commands it isn't
aware of? handleDefault()? Or should we define a new handleUnknown() method in Visitor
for this case, which would default to a no-op in AbstractVisitor? E.g., in a
module-specific command such as MyModuleCommand, I would implement:
>>
>> class MyModuleCommand implements ReplicableCommand {
>>
>> public Object acceptVisitor(InvocationContext ctx, Visitor visitor) throws
Throwable {
>> if (Visitor instanceof MyModuleVisitor) {
>> return ((MyModuleVisitor) visitor).visitMyModuleCommand(ctx, this);
>> } else {
>> return visitor.handleUnknown(ctx, this);
>> }
>> }
>>
>> }
>>
>> Cheers
>> Manik
>>
>> PS: There is no JIRA for this. If we like this approach and it works, I suggest
we create a JIRA and implement it for 4.2. The impl should be simple once we resolve the
outstanding bits.
>> --
>> 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
>
> --
> Manik Surtani
> manik(a)jboss.org
>
twitter.com/maniksurtani
>
> Lead, Infinispan
>
http://www.infinispan.org
>
>
>
>
> _______________________________________________
> 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
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev