Would anyone care to explain to me why I have to put the following in catalina.sh
JAVA_OPTS=-Djava.rmi.server.hostname=192.168.1.1
to get my RmiServiceExporter beans to bind to the correct NIC on my server?
Would anyone care to explain to me why I have to put the following in catalina.sh
JAVA_OPTS=-Djava.rmi.server.hostname=192.168.1.1
to get my RmiServiceExporter beans to bind to the correct NIC on my server?
By default, the host is localhost (127.0.0.1). I'm using RmiServiceExporter without problems, just declaring the bean.
I tried setting <property name="registryHost" value="192.168.1.12"/> but that doesn't work. Which property are you setting in your config?
I just do the following:
Server:
Client:Code:<bean class="org.springframework.remoting.rmi.RmiServiceExporter"> <property name="serviceName" value="EmprestimoFachada"/> <property name="service" ref="emprestimoFachada"/> <property name="serviceInterface" value="br.com.biblioshop.emprestimo.fachada.EmprestimoFachada"/> </bean>
Code:<bean id="emprestimoFachada" class="org.springframework.remoting.rmi.RmiProxyFactoryBean"> <property name="serviceUrl" value="rmi://localhost:1099/EmprestimoFachada"/> <property name="serviceInterface" value="br.com.biblioshop.emprestimo.fachada.EmprestimoFachada"/> </bean>
By the look of your client's url rmi://localhost, your client on the same host as your server. My client is on a different machine. That's what appears to cause the problem. Spring's "auto-registry" appears to bind to localhost by default (which is kind of daft for a "remoting" system).
If I specify the registryHost property explicitly, Spring appears to assume you want to use an existing application server's registry (which I don't have in my case as I'm in Tomcat). Setting "alwaysCreateRegistry" to "true" doesn't appear to do what you would expect either. Hmm.
It has nothing to do with Spring, it's how RMI works.
When you execute an RMI lookup server generates a stub and _hardcodes_ it's own address in it. Stub is then transfered to the client and address generated by the server used for method remoting. The address hardcoded in the stub has nothing to do with an address you used for a lookup. The algorithm used by the server to find it's own address is not very smart and fails to produce a meaningful result in all but trivial network configurations (very often it produces "localhost" so your rmi clients end up sending requests to themselves). That's why, most of the times, it's needed to override the algorithm by setting java.rmi.server.hostname.