|Summary:||Tribes | RpcChannel | Add option to specify external class loaders to support custom message classes|
|Product:||Tomcat 7||Reporter:||Olivier Costet <ocostet>|
|Component:||Cluster||Assignee:||Tomcat Developers Mailing List <dev>|
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 class. 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 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.