On Wed, Feb 23, 2005 at 10:30:51AM -0800, Jeremy Boynes wrote: > 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).
We key on string as it's a lot faster on the .equals call. > 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. Is it equally safe to assume the order won't change on the server? Things like EJB handles have to stay valid across server crashes and restarts. I want avoid anything that might cause the client and server versions of the name got fall out of sync. > 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. At current time, there is no chance there is going to be Geronimo or even 85% of the OpenEJB code on in a non-J2EE client. We've tried really hard to keep the openejb-client jar thin and free of dependencies. Anyway, I'm getting a little off-topic. -David
