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

On 30 Sep 2010, at 23:48, Israel Lacerra wrote: On Wed, Sep 29, 2010 at 4:06 PM, Manik Surtani <manik(a)jboss.org&gt; 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:

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(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

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(a)gmail.com&gt; wrote: On Thu, Sep 30, 2010 at 8:15 PM, Manik Surtani <manik(a)jboss.org&gt; wrote: On 30 Sep 2010, at 23:48, Israel Lacerra wrote: > > On Wed, Sep 29, 2010 at 4:06 PM, Manik Surtani <manik(a)jboss.org&gt; 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(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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)gmail.com&gt; wrote: On Thu, Sep 30, 2010 at 8:15 PM, Manik Surtani <manik(a)jboss.org&gt; wrote: On 30 Sep 2010, at 23:48, Israel Lacerra wrote: > > On Wed, Sep 29, 2010 at 4:06 PM, Manik Surtani <manik(a)jboss.org&gt; 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(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 _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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

On Oct 11, 2010, at 2:44 PM, Mircea Markus wrote: > I've implemented a POC as per your suggestions, my comments bellow. > On 29 Sep 2010, at 20: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. > directly should not be a problem. >> >> 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? > that's a more complex issue and has to do with managing the serialization of custom commands through our marshalling framework. Right now we cannot register marshaller at runtime, until https://jira.jboss.org/browse/ISPN-244 is implemented. > My POC is based on java serialization - far from being optimal it can represent an approach till 5.0 is released. If your class extends Externalizable, things are not that bad tbh. Our Externalizer is the very best, but Externalizable should work pretty well. Remember that part of the java serialization problem is the OOS/OIS which we don't use any more since we have JBoss Marshalling. >> >> * How do interceptors defined in the core module handle commands it isn't aware of? handleDefault()? > what about just invokeNext? this would make only the interceptors that are extensions to do any work. >> 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: > works as well. >> >> 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. > there is one actually: https://jira.jboss.org/browse/ISPN-256 > I'll attache the patches to it. > Just to conclude, I've POC both approaches GenericCommand and ExtendingCommand, here are my thoughts on it: > - extending visitor > PROS: ExtendingCommand is a better OO API, more strongly typed > CONS: it is harder for the user to understand; integrating custom serialization might be difficult(impossible at the time), also it will have to manage command uniques.

> > > - GenericCommand > CONS: > - less OO API > - would require a "convention" for not "overusing" it. Overuse would be in client code though, not in ours > PROS: > - easier for the user to understand and use > - no need for extra classes needed > - no understanding of how the interceptor chain internals work needed (for writing acceptVisitor). > - no understanding of how serialization works is needed. Nor command uniques. > - easy streight-forward solutions > > I would go for GenericCommand, but Extending approach works for me as well.

> > Cheers, > Mircea >> -- >> 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 > > _______________________________________________ > 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

On 11 Oct 2010, at 13:44, Mircea Markus wrote: >> >> 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. > there is one actually: https://jira.jboss.org/browse/ISPN-256 > I'll attache the patches to it. > Just to conclude, I've POC both approaches GenericCommand and ExtendingCommand, here are my thoughts on it: > - extending visitor > PROS: ExtendingCommand is a better OO API, more strongly typed > CONS: it is harder for the user to understand; integrating custom serialization might be difficult(impossible at the time), also it will have to manage command uniques. Why is this hard for developers to understand? Remember, these aren't *application* developers, but people *extending* Infinispan. They already ought to have an in-depth knowledge of Infinispan.

What do you mean by "command uniques"?

> - GenericCommand > CONS: > - less OO API > - would require a "convention" for not "overusing" it. Overuse would be in client code though, not in ours Client code may well be our code. E.g., more modules that we ship. -1 to a weakly typed API like this. Conventions cannot be enforced, and IMO if something can be abused, then it will be abused. :)

> PROS: > - easier for the user to understand and use > - no need for extra classes needed > - no understanding of how the interceptor chain internals work needed (for writing acceptVisitor). Why would someone write a visitable command and not care about an interceptor that visits it? Surely you would only write a visitable command if you *want* to visit it with an interceptor

> - no understanding of how serialization works is needed. Nor command uniques. ? What's so hard about this? "implements Externabilzable" is the easy way, @Marshallable() a slightly more roundabout way for greater efficiency in marshalling.

> - easy streight-forward solutions > > I would go for GenericCommand, but Extending approach works for me as well. -- 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

On 25 Oct 2010, at 13:25, Mircea Markus wrote: >> ? What's so hard about this? "implements Externabilzable" is the easy way, @Marshallable() a slightly more roundabout way for greater efficiency in marshalling. > what about managing unique command numbers? That's only if you use @Marshallable. Implementing Externalizable doesn't have this issue. And there is a unit test that tests for duplicate command IDs (if the command is a part of the Infinispan src tree)

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

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

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

Nice stuff!

Manik, It's look pretty fine to me and will solve my problem :) Israel On Tue, Mar 8, 2011 at 11:43 AM, Manik Surtani <manik(a)jboss.org&gt; wrote: > > On 7 Mar 2011, at 13:02, Mircea Markus wrote: > > > Nice stuff! > > What do you think from the perspective of having to implement your own > commands, say for the continuous query prototype you did? Does it fit with > that model? > > Also, any more feedback from module authors that need this (looking at > Sanne and Israel!)? If not, I'll go ahead and issue a pull req... > > Cheers > Manik > > -- > 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 >

Israel, do you have a test case for this? On Jun 6, 2011, at 7:23 AM, Israel Lacerra wrote: > Manik, > > I think there is a little problem. If a custom command use the same id of a core command...no exception is thrown. > > cheers > > Israel > > On Thu, Mar 10, 2011 at 9:25 PM, Israel Lacerra <israeldl(a)gmail.com&gt; wrote: > Manik, > > It's look pretty fine to me and will solve my problem :) > > Israel > > On Tue, Mar 8, 2011 at 11:43 AM, Manik Surtani <manik(a)jboss.org&gt; wrote: > > On 7 Mar 2011, at 13:02, Mircea Markus wrote: > > > Nice stuff! > > What do you think from the perspective of having to implement your own commands, say for the continuous query prototype you did? Does it fit with that model? > > Also, any more feedback from module authors that need this (looking at Sanne and Israel!)? If not, I'll go ahead and issue a pull req... > > Cheers > Manik > > -- > 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 > > > _______________________________________________ > 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

Israel, do you have a test case for this? On Jun 6, 2011, at 7:23 AM, Israel Lacerra wrote: > Manik, > > I think there is a little problem. If a custom command use the same id of a core command...no exception is thrown. > > cheers > > Israel > > On Thu, Mar 10, 2011 at 9:25 PM, Israel Lacerra <israeldl(a)gmail.com&gt; wrote: > Manik, > > It's look pretty fine to me and will solve my problem :) > > Israel > > On Tue, Mar 8, 2011 at 11:43 AM, Manik Surtani <manik(a)jboss.org&gt; wrote: > > On 7 Mar 2011, at 13:02, Mircea Markus wrote: > >> Nice stuff! > > What do you think from the perspective of having to implement your own commands, say for the continuous query prototype you did? Does it fit with that model? > > Also, any more feedback from module authors that need this (looking at Sanne and Israel!)? If not, I'll go ahead and issue a pull req... > > Cheers > Manik > > -- > 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 > > > _______________________________________________ > 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

So far command IDs have been bytes, so using ranges is harder. We'd need to change them to short or something bigger to be able to use ID ranges relatively safely. On Jun 8, 2011, at 2:25 PM, Manik Surtani wrote: > Isn't the approach here to use well-known ID ranges? A bit like externalizers? > > On 6 Jun 2011, at 11:29, Galder Zamarreño wrote: > >> Israel, do you have a test case for this? >> >> On Jun 6, 2011, at 7:23 AM, Israel Lacerra wrote: >> >>> Manik, >>> >>> I think there is a little problem. If a custom command use the same id of a core command...no exception is thrown. >>> >>> cheers >>> >>> Israel >>> >>> On Thu, Mar 10, 2011 at 9:25 PM, Israel Lacerra <israeldl(a)gmail.com&gt; wrote: >>> Manik, >>> >>> It's look pretty fine to me and will solve my problem :) >>> >>> Israel >>> >>> On Tue, Mar 8, 2011 at 11:43 AM, Manik Surtani <manik(a)jboss.org&gt; wrote: >>> >>> On 7 Mar 2011, at 13:02, Mircea Markus wrote: >>> >>>> Nice stuff! >>> >>> What do you think from the perspective of having to implement your own commands, say for the continuous query prototype you did? Does it fit with that model? >>> >>> Also, any more feedback from module authors that need this (looking at Sanne and Israel!)? If not, I'll go ahead and issue a pull req... >>> >>> Cheers >>> Manik >>> >>> -- >>> 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 >>> >>> >>> _______________________________________________ >>> 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 > > -- > 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

2011/6/8 Manik Surtani <manik(a)jboss.org&gt;: > Any other ideas then, around this? Maybe a check during startup, when ModuleCommandFactory. getModuleCommands() is invoked? +1 we don't have to check for proper ranges, but we should check for duplicates.

> > > On 8 Jun 2011, at 15:42, Galder Zamarreño wrote: > >> So far command IDs have been bytes, so using ranges is harder. We'd need to change them to short or something bigger to be able to use ID ranges relatively safely. >> >> On Jun 8, 2011, at 2:25 PM, Manik Surtani wrote: >> >>> Isn't the approach here to use well-known ID ranges? A bit like externalizers? >>> >>> On 6 Jun 2011, at 11:29, Galder Zamarreño wrote: >>> >>>> Israel, do you have a test case for this? >>>> >>>> On Jun 6, 2011, at 7:23 AM, Israel Lacerra wrote: >>>> >>>>> Manik, >>>>> >>>>> I think there is a little problem. If a custom command use the same id of a core command...no exception is thrown. >>>>> >>>>> cheers >>>>> >>>>> Israel >>>>> >>>>> On Thu, Mar 10, 2011 at 9:25 PM, Israel Lacerra <israeldl(a)gmail.com&gt; wrote: >>>>> Manik, >>>>> >>>>> It's look pretty fine to me and will solve my problem :) >>>>> >>>>> Israel >>>>> >>>>> On Tue, Mar 8, 2011 at 11:43 AM, Manik Surtani <manik(a)jboss.org&gt; wrote: >>>>> >>>>> On 7 Mar 2011, at 13:02, Mircea Markus wrote: >>>>> >>>>>> Nice stuff! >>>>> >>>>> What do you think from the perspective of having to implement your own commands, say for the continuous query prototype you did? Does it fit with that model? >>>>> >>>>> Also, any more feedback from module authors that need this (looking at Sanne and Israel!)? If not, I'll go ahead and issue a pull req... >>>>> >>>>> Cheers >>>>> Manik >>>>> >>>>> -- >>>>> 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 >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> -- >>> 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 > > -- > 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 > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev