We Keep Coding

Java RMI: multiple rmiregistry on the same machine

We are developing a client-server application with Java RMI and, for testing, we will use a computer both as client and as server. So both the client and the server applications must call rmiregistry on the same machine, but they are two different JVMs obviously. How can we do that? We hoped that it was necessary only to give different ports to LocateRegistry but we get NotBoundException...
What is the correct way?

You can run as many as you like, but why? You don't need to. Have the server start its own Registry via LocateRegistry.createRegistry(), and have the client lookup that one. You seem to think the client needs its own Registry, which isn't correct.
If you got a NotBoundException clearly either the service wasn't bound at all in any registry, or you looked up the wrong one.

RMI Registry is a server which maintains a registry of services.
So your server should connect to the RMI registry and register itself in it, while client should connect to RMI registry and look up your server
So you need to run a single RMI Registry on your machine.
It seems that you're getting the NotBoundException cause you have two of them

Best way to tunnel RMI over HTTP

I'm looking for a secure way to tunnel RMI traffic.
In My application(java Webstart) i must assume that the only port that is open is port 80.
I have the looked att socketfactories for rmi but do i really need a proxy then.
I need to do all my tunneling on the client side.
The only firewall i am trying to get past is on the client side.
I'm not able to open 1099 with port ranges above.
Would be nice to see some implementations.
Thanks!

Port 1099 was reserved for RMI at IANA in about 1995. There is no reason for it not to be open for outbound access in the client-side firewall.
RMI can be made to use fixed port numbers by supplying a port number when constructing (super(port)) or exporting (exportObject(object, port)). Better still, if you create the Registry within the server JVM via LocateRegistry.createRegistry(), all subequently exported remote objects will use that port unless they specify a different port or they use a server socket factory.
BUT ... RMI already includes HTTP tunneling 'out of the box'. No external solution required. You have to deploy the RMI-Servlet provided with the JDK, at the server end.

(a)
although not the newest fashion, exposing remote services with Hessian and Burlap seems to be a simple solution to avoid problem working across firewalls: http://hessian.caucho.com/doc/
see sample code for the server and client side:
http://www.javatpoint.com/spring-remoting-by-hessian-example
(b) or consider using Spring HttpInvokder (see some sample code here: http://www.javatpoint.com/spring-remoting-by-http-invoker-example)
HttpInvokder provides more customization options through the RemoteInvocationFactory, RemoteInvocationExecutor and HttpInvokerRequestExecutor strategies (for example, to add custom context information (such as user credentials) to the remote invocation, or using java’s built-in object serialization etc.), see:
http://docs.spring.io/spring-framework/docs/2.0.x/api/org/springframework/remoting/support/RemoteInvocationFactory.html

Using same port for Server and remote JMX beans

We are using Embedded Jetty as our webserver running on port 8080 and want to monitor the application on Jconsole. We are using the following system property when starting the Jetty server specific to JMX:
-Dcom.sun.management.jmxremote.access.file=jmxremote.access
-Dcom.sun.management.jmxremote.password.file=jmxremote.password
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.port=8081
Although, JMX and Webserver are running on two different ports, is there a way for client to access JMX via Jconsole/JvisualVM using port 8080? Is JMX Proxy going to help me in anyway? Is it possible in any way?
Thanks in advance.
Ajay

Not without some effort. In a nutshell, there can always only be a single server on one port (or the other way around: Servers can't share a port).
If JMX was supporting HTTP requests, then you could run it as a servlet on the same HTTP server. There would be one port (used by the HTTP server) and then the HTTP URLs would allow the server to determine whether the client wanted to talk to JMX or the web application.
But JMX doesn't support HTTP requests directly. You can try Jolokia (see this question) or you can write servlets which allows a client to query certain mbeans (but without JMX protocol).

JMX specification have Connector that can use any protocol as transport, see http://en.wikipedia.org/wiki/File:Jmxarchitecture.png

Java JMX Server

I'm curious about how JConsole and JMX work together. Specifically, I have read this JConsole Guide which mentions that
jconsole uses a JMXConnector client to connect to the JMXConnectorServer in
the target application. If the application isn't started with the JMX agent
then there isn't a JMXConnectorServer and jconsole doesn't have anything to
connect too. In that case it uses a HotSpotTM VM specific mechanism to start
the JMX agent in the target VM. Once the agent is started then jconsole connects
as normal.
When I start jconsole it simply needs a port and hostname for the JMX information, so I'm wondering if its possible to access the MBeans through any arbitrary tcp connection (and thus any programming language), or if there is something special that jconsole is also doing?
I know how to access the MBean Factory though java, but I am curious if I can access these items through an arbitrary language via TCP or another straightforward mechanism. Also see link discussing rest connector.

By default, the JMX server provides connection via RMI. That will make it tricky to access the server through an arbitrary language.
However, the JMX server is not limited to RMI as the communication protocol. The architecture is extensible and pretty much any transport protocol might be used - but it would need to be written almost from scratch.
Take a look at Jolokia - they do a pretty amazing stuff to let you talk to the MBean servers via a bunch of protocols (REST is one of them), amongst other things.

rmi registry binding issue

I'm running RMI Regitry on a virtual machine (running Windows XP) with IP: 192.168.133.2
and trying to bind an RMI server (running on different vm XP IP: 192.168.133.3)
by using this code:
Naming.rebind("//192.168.133.2/rmi.2", new RMI());
where
public class RMI extends UnicastRemoteObject
but I get this exception:
java.rmi.AccessException: Registry.Registry.rebind disallowed; origin /192.168.133.3 is non-local host
I figured that the RMI Registry don't accept any rmi server which isn't running on the same
RMI Registry running machine.
but how to make this registry accept my rmi server?
p.s: I'm using JBuilder X as an IDE.
I'm trying to implement a mobile agent which will run on some rmi servers to do some work on them and return the results to the starting station so RMI servers implements the environment that hosts this agent to do its work and send it to the next station which it'll locate through the registry

trying to bind an RMI server (running on different vm XP IP: 192.168.133.3)
Stop right there. You can't do that. You can only bind an RMI server to a Registry running in the same host as the agent that is doing the bind.
Note that that does not necessarily mean the same host as the remote object itself is running in. For example, a client could lookup a remote Registry and bind the stubs retrieved into the local Registry. But you cannot bind anything to a remote Registry.

RMI doesn't provide any sort of "federated" or distributed naming service.
RMI is structured to allow you to run an RMI registry on your server. It hosts services that can be accessed across the network, however the services run locally on that server.
The service being provided must be started - and "rebind" - on the server - not on any client system. Local address only.
Your clients should then reach out to that server...