JBossDeveloper

Why does it need to be strongly typed ? Invocation.getValue() has served us nicely for a long time...
We will, of course, add methods to Invocation which hide the narrowing, e.g. Invocation.getTransaction(), which already exists BTW. But this is more syntactic sugar...

For all the reasons Java is a strongly typed language, and for all teh reasons why we don't just declare everything as Objects. :)

Invocation.getValue() is fine for generic, user defined content but when it is something specific to the operation of a product, such as tx, gtx, etc., I would much rather have it as typed. Compile time checking, easier reference for users when implementing custom interceptors, more readable code with fewer casts and type checks, etc.

I agree it is syntactic sugar but I do think it is worthwhile. So, whether we implement it by subclassing MethodCall and adding the syntactic sugar on the subclass or some other mechanism, I think we should do it when the time comes.

For now, keeping with the trend, I'd like to make InvocationContext typed as well, with the assumption that we will have typed methods later as well.

The problem is that the data transported in the payload is not finite, we know a few data types we use ourselves (e.g. Options, Transaction), but users can add anything they want. It is very important that we don't have to change (= extend) the signature every time we ship some other data as payload.
I'm also against subclassing for this purpose: a subclass simply adds to a proliferation of long instanceof if-then-else statements. Users know what they add to the payload, and we give them the freedom to access those types through an untyped method. Of course, for frequently used types, we can also add syntactic sugar, like getTransaction().
We have untyped payloads in JGroups (headers) and JBoss (Invocation payload), and it has worked very well.

Yes, I agree that untyped payloads is fine for generic, user defined content.

But for content internal to JBossCache - such as Options and Transactions - I'd rather have the syntactic sugar. Pretty much what I'm proposing.

Whether we do it in a subclass or in the MethodCall object, thats up to you - just that defining these types in MethodCall will add a dependency that JGroups needs to know about Transactions, GlobalTransactions, Options.