On Sep 29, 2010, at 9:06 PM, 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?
There's some similarities between the problem of IDs and resolution and the problem of
Externalizers and their IDs. A similar approach could be taken for both wrt to handling
internal IDs vs user IDs?
https://jira.jboss.org/browse/ISPN-244
Also, it'd be helpful if the registration API for both commands and/or Externalizers
in similar way.
* 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);
}
}
}
Hmmm, not sure it is necessary. It seems like handleDefault and handleUnknown would do the
same which is ignore the call and pass up. From a client pov, handleUnknown() is likely to
be more meaningful rather than handleDefault though but I don't think it's such a
big diff.
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
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache