geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: GBeanName [was: svn commit: r154723...]
Date Wed, 23 Feb 2005 18:30:51 GMT
Dain Sundstrom wrote:
> On Feb 23, 2005, at 9:16 AM, Jeremy Boynes wrote:
> 
>> David Blevins wrote:
>>
>>> The protocol layer in OpenEJB uses the canonical string version all 
>>> over the place.  We avoided ObjectName on the wire as String is 
>>> capable of representing an ObjectName and serializes faster and with 
>>> less bytes as there is special logic in 
>>> java.io.ObjectOutput/InputStream that basically treats them like 
>>> primitives.
>>
>>
>> I take it you have some form of custom serialization code that 
>> converts ObjectName to String and back again. GBeanName is 
>> Serializable (and the serialized form is just a String) so it should 
>> continue to work right now until you can add custom serialization just 
>> as for ObjectName.
> 
> 
> OpenEJB sends the string to the client and sometimes gets a string back 
> (ejbs are indexed by number for speed).  When a string comes back it is 
> looked up directly into a hash, keyed on the string.  The means that 
> OpenEJB clients do not see any Geronimo code.  If GBeanNames were used, 
> then the client would need a GBeanName class.
> 

I don't see the issue - OpenEJB can still send Strings to the client, it 
just needs to convert then into GBeanNames /back on the server/ before 
looking them up in its map; or ObjectNames, or whatever it wants to key 
the map on (although GBeanName seems intuitive). As you are already 
assuming the client is not going to be reordering the String you send 
it, then it seems to me that things would be unchanged.

Anyway, isn't there a good chance there is going to be Geronimo code on 
the client anyway? Given this is a proprietary protocol, there is a high 
likelihood the client is some form of Geronimo server (e.g. an 
application client, web server, another OpenEJB server, or just a 
"remote" client in-VM) and where it is a non-J2EE client then its going 
to need OpenEJB jars anyway.

--
Jeremy

Royal Blue, with a faint hint of Aquamarine!

Mime
View raw message