are now working in 3.1 (CVS HEAD). Marc: your vision is real!!! Even
concurrent JRMP and IIOP invocations appear to be working fine. I have
committed yet another version of the hello test (hellojrmpiiop) to
demonstrate this.
Here is a summary of the recent changes on the IIOP stuff in 3.1:
- The EJB-specific IIOPContainerInvoker is gone. Its functionality
is now split between a generic IIOPInvoker MBean and an EJB-specific
IORFactory, which is the IIOP version of a ProxyFactory.
- These two guys interact in the following way: the IORFactory registers
CORBA servants with the IIOPInvoker, which returns to the IORFactory
reference factories the IORFactory uses to create CORBA references.
Two new interfaces are involved: ServantRegistry and ReferenceFactory,
both implemented by objects provided/returned by the IIOPInvoker.
- An IORFactory is associated to a given container. It creates two CORBA
servants: an EjbHomeCorbaServant and an EjbObjectCorbaServant. Both are
thin wrappers that forward invocations to the container, through the
JBoss MBean server.
- Other CORBA reference factories (which don't need to be EJB-specific)
may also use the IIOPInvoker. As an example, the in-VM CORBA naming
service in 3.1 has been modified to register its servants with the
IIOPInvoker. A next step would be an IIOP Java proxy factory that talks
to the IIOPinvoker. (Any volunteers?...)
- The CORBA naming service has been taken off the CORBA ORB service and
is now a separate MBean.
- IIOP-specific container configurations are gone. Now you just
specify the iiop <invoker-proxy-binding>.
- The <proxy-factory-config> of an IORFactory takes the following
sub-elements (see iiop proxy binding in standardjboss.xml):
- <web-class-loader>: Moved from the container configuration.
Must contain org.jboss.iiop.WebCL.
- <poa>: May be shared (a single POA shared among all servants
bound to a ServantRegistry) or per-servant (a separate
POA is created for each servant bound to a ServantRegistry).
The default value in the iiop
<invoker-proxy-binding> in standardjboss.xml is per-servant.
- <register-ejbs-in-jnp-context>: If true, EJBHome IORs are registered
with the JBoss JNP naming service in addition to being
registered with the CORBA naming service. If false EJBHome
IORs are registered only with the CORBA naming service.
The default value in the iiop <invoker-proxy-binding> in
standardjboss.xml is true.
- <jnp-context>: Only meaningful it the previous element is true.
Specifies the JNP naming context EJBHome IORs will be bound to.
If absent, EJB IORs will be bount to the root JNP naming
context. The default value in the iiop <invoker-proxy-binding>
in standardjboss.xml is iiop.
To clarify the last two config elements: in the hellojrmpiiop test,
the JRMP reference to the EJBHome is bound to "helloworld/Hello" in the
JNP naming service. The EJBHome IOR is bound to "helloworld/Hello" in the
CORBA naming service and to "iiop/helloworld/Hello" in the JNP naming
service (because <register-ejbs-in-jnp-context> is true and <jnp-context>
is iiop).
Let me know what you think of this arrangement. Suggestions/ideas are very
welcome. And please let me know of any problems.
This stuff is built upon Bill's great work on multiple invokers. It is
also a consequence of very enlightening discussions with Marc and Bill.
Thanks, guys!
Best,
Francisco
_______________________________________________________________
Hundreds of nodes, one monster rendering program.
Now that's a super model! Visit http://clustering.foundries.sf.net/
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
