Bug 50670

Summary: Tribes | RpcChannel | Add option to specify external class loaders to support custom message classes
Product: Tomcat 7 Reporter: Olivier Costet <ocostet>
Component: ClusterAssignee: Tomcat Developers Mailing List <dev>
Severity: enhancement Keywords: PatchAvailable
Priority: P2    
Version: 7.0.6   
Target Milestone: ---   
Hardware: All   
OS: All   
Attachments: svn diff

Description Olivier Costet 2011-01-27 08:45:43 UTC
Since the tribes classes are loaded by the tomcat loader, if the messages
sent through tribes are instances of classes defined in the webapp, attemps to
deserialize them will fail. AbstractReplicatedMap includes a mechanism for the
API user to specify class loaders to be used when deserializing map entries.
This entry proposes a similar mechanism for the RpcChannel.
Comment 1 Olivier Costet 2011-01-27 08:46:47 UTC
Reproducing comments from https://issues.apache.org/bugzilla/show_bug.cgi?id=50648:

Filip Hanik wrote:
> 3.
> The external loaders IMHO don't belong here.
> For the applications that wish to provide custom class loading, I would simply
> send messages using the ByteMessage class. That way you have full control over
> what is happening.

It's true, you could use ByteMessages. Although as an API user, your code would
become more clunky, and you'd lose the ability to quickly look up the message's
Wouldn't it be nice to have, though? It makes things easier, cleaner and
doesn't add any significant overhead. Also, as things stand, the tribes API is
somewhat misleading in that it offers to send Serializable messages (methods
like Channel#send take Serializable arguments), when in practice all your app's
classes are excluded, no matter how Serializable they may be.
Comment 2 Olivier Costet 2011-01-27 08:47:54 UTC
Created attachment 26560 [details]
svn diff
Comment 3 Mark Thomas 2018-05-16 10:23:15 UTC
I've no strong view on this so I am going to follow Filip's view that this is not necessary.