geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: svn commit: rev 51845 - in geronimo/trunk/modules/assembly/src: plan var/config
Date Mon, 04 Oct 2004 15:59:55 GMT
On Oct 4, 2004, at 12:40 AM, jastrachan@mac.com 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


Mime
View raw message