This is mostly directed at David Blevins as a follow up to the
conversation we had on this topic a couple of weeks ago.
David, I'm starting to attack the CORBA problem from the standpoint of
having the CORBA naming service function like the JNDI context. In
order to do this, I will end up needing to activate different servant
instances on the hosting ORB. From a CORBA standpoint, the servant
instance is an object that fields method invocation requests and handles
marshaling of the arguments and return values.
Currently, the embodiment of the servant used for the Geronimo CORBA
support is in the StandardServant class. There's a single class that
can handle all of the different EJB types. In general, the a
StandardServant object gets created whenever an object is "activated" on
the ORB, and the important information it holds is the EJBDeployment for
the bean and the primary key (which will be null in places where it
doesn't make sense).
This should be relatively straightforward to make the naming context
hook up, but unfortunately, the JNDIRequest/JNDIResponse processing used
by JNDIContext doesn't appear to give me a mechanism for accessing the
EJBDeployment information. Is there some other mechanism I can use to
make the mapping back to the deployment information? Or would it be
more appropriate to add another request type to JNDIRequest to perform a
CORBA-related lookup? From a CORBA standpoint, I'd only want Context
and EJBDeployment information....which is really a small subset of what
JNDIRequest is handling on a lookup.
Rick
