On Oct 13, 2010, at 9:02 AM, Galder Zamarreño wrote:
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.
Again, this is not true. You can do custom serialization extending java.io.Externalizable
which should be more than good enough for 4.2.x.
What you cannot do is: Take a class that's non serializable (iow, does not extend
Serializable or Externalizable) and provide an Externalizer for it.
>
>
> - 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.
Havent' looked at the patches yet, but I think prefer a more strongly typed version
bearing in mind that the java serialization issue is not really a problem.
I'll see if I can check the patches before end of week.
>
> 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
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache