On Oct 4, 2004, at 12:40 AM, [EMAIL PROTECTED] wrote:
On 4 Oct 2004, at 04:03, Hiram Chirino wrote:Yes, user code only uses the JMS API. But the client is indirectly using ActiveMQ classes since the JMS interfaces are ActiveMQ implementations. And since the in vm transport does not serialize the ActiveMQ messages it sends to the broker, the broker needs to be in the same classloader as the app. Otherwise, I'm sure the server would throw class cast exceptions.
If you're sending a message from one EAR to another using user objects serialized, thats true. I guess in this case, we should ensure that the tcp protocol is used to ensure data is serialized into and out of each EAR/class loader.
It is only true if the objects passing over the transport are private to the ear. If the object are standard J2EE types (e.g., javax.jms.MapMessage) or are standard J2EE types (e.g., java.lang.String), there will be no class cast exceptions. I believe this is the normative case.
We should reserve the VM transport for use cases where publishers and consumers are in the same class loader - will add warnings to the website to this effect.
You can use the trick Hiram uses in Geronimo Remoting. He checks that the class loader of the source class is a parent of the target class loader. If they are not, he does a serialization copy. The only question is is the check expensive.
-dain
