[infinispan-dev] Defining new commands in modules

Manik Surtani manik at jboss.org
Fri Mar 4 21:32:10 EST 2011


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/a6085647f2ac908d9307c9cd6866ed412bc12406

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/java/org/infinispan/commands/RemoteCommandsFactory.java?r=2327#l59
> 
> 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 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

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org






More information about the infinispan-dev mailing list