weblogic.httpd.requireAuthentication=false
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Marko �trukelj
Sent: Thursday, March 01, 2001 9:18 AM
To: '[EMAIL PROTECTED]'
Subject: [jBoss-User] RMI through HTTP proxy
Hi,
I've been playing with the possibility of doing rmi on beans deployed in jboss through HTTP proxy and there are some things that are very funny, so if someone can clarify things it would be great.
Ok. When there is a code like this in the client:
InitialContext ctx=new InitialContext();
BeanHome home=(BeanHome) ctx.lookup("MyBean");
Bean remote=(Bean) home.findByPrimaryKey("1");
String something=remote.getSomething();
A network connection is opened when lookup is done. Connections to port 1099, 5555 and 4444 are opened.
Port 1099 is used by jnp - it uses it's own protocol and doesn't allow for HTTP proxy tunneling.
Port 5555 also seems to be used by jnp, without client being allowd to connect out to that port, ctx.lookup can not succeed.
I suspect it doesn't allow for HTTP Proxy tunneling.
4444 is a standard rmi port - I guess it uses jrmp and should work like the rmi specification claims and in case we disable port 4444 attempt a proxy. How does java know on which host:port to look for proxy? Seems it doesn't. You can find on varous chat forums how you could tell that to jdk 1.1.x :
You could supposedly put these on your command line:
-DproxySet=true -DproxyHost=myproxyhost -DproxyPort=8080
But the truth is, this doesn't work with jdk1.3
rmi doesn't make any attempt to any port other that 4444. It doesn't try direct connection to port 80, it doesn't try a proxy server, it just doesn't. This is what I find very funny, since there is whole chapters in rmi specification dedicated to proxy tunnelling and there is even a servlet as a replacement for .cgi to be used for proxy-ing RMI via HTTP.It seems to me that if I wanted a client to talk to an EJB server (either jboss or some other), without making any change in the existing code, then what I would have to do would be:
Write my own jndi implementation, replace
-Djava.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
with something like
-Djava.naming.factory.initial=com.mine.NamingContextFactory.
This implementation would allow for configuring the proxy host and proxy port and would wrap all lookup requests in HTTP POST messages, send them to machine B where HTTP proxy is located and that would forward it to machine C where jboss and my naming service implementation is located. My naming service would act as a proxy to jnp. It could be written so that there would be no need to explicitly bind names to it, whatever requests it got it would just attempt them on jboss. It would wrap the results and send them back.
But! If we just wrapped the results we would still have proxies on the client that would attempt to communicate through jrmp - which won't work. So what we need to, we need to manage what jboss returns on the server side and send our implementation of proxy objects and stubs to the client side, so all rmi calls will be marhalled into HTTP POST request, unmarshalled and forwarded thoru remote calls on objects that jboss returned, then the results marhalled into HTTP responses and sent back.
Thus far it looks like a real mess.
Is there any other way that would be EJB server independent?
I know there is zoap, but you have to make remote calls in completely different way, also you have bunch of complications deploying your beans. Because you had to code your client differently you can not go back to direct rmi in environments that allow that.
Thanks for any comments,
Marko.
