RMIJRMPServerImpl

Adriana Danes <[email protected]>
Newsgroups gmane.comp.java.mx4j.devel
Message-ID <[email protected]>
Hello,

We have a problem related to the 
javax.management.remote.rmi.RMIJRMPServerImpl class when
creating a JSR 160 JMXConnectorServer in the JOnAS application server.

This problem only occures in a particular configuration case - when trying
to start a JOnAS server which does not start its own registry service, 
but uses (shares) the registry
service of a previously started JOnAS server.
In this situation, when using *JRMP* protocol, the 
RMIConnectorServer.start() fails, as the
RMIJRMPServerImpl.export() fails with a "java.net.BindException: Address 
already in use" exception.
However, in the same situation, when using *IIOP* protocol, everything 
goes well.

When comparing the 2 implementations of RMIConnectorServer
(RMIJRMPServerImpl and RMIIIOPServerImpl), we can see that the main 
difference consists
in using UnicastRemoteObject in the JRMP case, and PortableRemoteObject 
in the IIOP case.
For us (in JOnAS), PortableRemoteObject is perfect as when executing the 
exportObject() method,
the proDelegate is checked, and in case its not null, then the 
exportObject() is called on the proDelegate
object. This is not the case with UnicastRemoteObject. Delegating the 
exportObject to proDelegate
permits passing towards the JOnAS registry service, which is the desired 
behaviour for us.

So, my question is why this difference between the 2 implementation 
classes ?
And second, do you think it should be possible to use 
PortableRemoteObject in the RMIJRMPServerImpl
class, instead of UnicastRemoteObject ?

Regards,

Adriana Danes




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.