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!
