Hi,
I have committed to contrib/iiop a preliminary version the IIOP
container invoker. The container invoker classes are in packages
org.jboss.ejb.plugins.iiop and org.jboss.ejb.plugins.iiop.server.
They use Ole's RMI/IIOP mapping classes (package org.jboss.iiop.rmi).
Ole:
Thanks for the home POA in your CorbaORBService MBean. Already switched to
it. Very convenient, indeed.
Saw you have also set up an in-VM naming server, great. I am not using it
yet, but soon will.
On Sun, 12 Aug 2001, Ole Husgaard wrote:
> This still leaves the question on how the clients get a
> reference to the naming service. But I guess we have to
> address this anyway to avoid using the SUN-specific class
> com.sun.jndi.cosnaming.CNCtxFactory at client-side.
This class is in Sun's jdk 1.x for x >= 3. It does the CosNaming/JNDI
mapping, RMI/IIOP clients need it to access the CORBA name service through
JNDI. Pure CORBA clients can use the org.omg.CosNaming stubs instead.
Switching subjects a little bit... Some time ago you wrote it would be
nice to have some sort of generic RMI/IIOP stub to be used by clients.
At that time I thought a generic stub would be very hard to do. I have
changed my mind.
A generic RMI/IIOP stub would mirror the generic skeleton in
IIOPContainerInvoker. It would use a pair of HashMaps from Methods to
StubStrategies, just like the generic skeleton uses a pair of HashMaps
from Strings to SkeletonStrategies.
The StubStrategy class would be quite similar to the SkeletonStrategy.
It would even use the same set of auxiliary reader and writer classes.
(By the way, this is why I reorganized these marshalling/unmarshalling
classes a little bit. And renamed my old MethodDescriptor class to
SkeletonStrategy, implying there might be a StubStrategy sometime.)
A generic stub would be a DynamicProxy, in order to be independent of
its remote interface. The stub _code_ would be a "one size fits
all" thing, but its _data_ (the pair of HashMaps) would be
interface-dependant.
The generic stub would download its pair of HashMaps from the server,
which created them at deployment time. This seems to be the single
non-trivial part...
Best regards,
Francisco Reverbel
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
