The server side of OpenEJB is responding with a different protocol than the client is using. The OpenEJB client side class Client, in it's processRequest() method, as part of the handshake with the server, is sending a ClusterRequest object to the server. The CluserRequest object contains the correct URI, "ejbds://127.0.0.1:4201", but when the server responds with a ClusterResponse object later in the processRequest() method, the URI is "ejbd:0.0.0.0:4201". This URI's protocol, ejbd, is then used for all future connections to the server, which fails, as noted in the last post.
Is OpenEJB's support of SSL incomplete? Thanks in advance. bitz wrote: > > I figured out a way to set the server side 'secure' boolean on > ServerDaemon. I can pass -Dejbd.secure=true to the JVM. Not sure if this > is the correct way to do it, but it gets me a little further. The client > ctx.lookup() is successful, so the client connects to the server ok, at > least once. On the subsequent call to my remote method, > remote.getServerTime(), the OpenEJB client code no longer knows that the > connection should be ejbds. It's reverting to ejbd, and creates a > standard Socket instead of SSLSocket. The remote method call fails. I'll > keep debugging, but it looks like there might be a defect somewhere, > unless I'm doing something wrong. > > > > bitz wrote: >> >> I'm using a snapshot of geronimo 2.2 which uses OpenEJB 3.1.2. I'm >> writing a test application to try out ejbds, which provides support for >> OpenEJB client-server communications over SSL. According to these, >> >> http://www.nabble.com/EJBd-protocol-over-SSL-td22188312.html >> http://issues.apache.org/jira/browse/OPENEJB-785 >> >> it should work. I'm running the client and Geronimo on the same machine. >> Here's my client code, >> >> final URI serverURI = new URI( "ejbds", null, "127.0.0.1", 4201, null, >> null, null ); >> final Properties contextProperties = new Properties( ); >> contextProperties.put( Context.INITIAL_CONTEXT_FACTORY, >> "org.apache.openejb.client.RemoteInitialContextFactory" ); >> contextProperties.put( Context.PROVIDER_URL, serverURI.toString( ) ); >> contextProperties.put("ejbd.secure", "true"); >> >> final InitialContext ctx = new InitialContext( contextProperties ); >> final MyEjbService remote = (MyEjbService)ctx.lookup("MyEjbRemote"); >> final String serverTime = remote.getServerTime(); >> System.out.println("server time: " + serverTime); >> >> The OpenEJB client code is detecting "ejbds" as the protocol and creating >> an SSLSocket, but the client fails on the ctx.lookup() call. >> >> java.lang.RuntimeException: Invalid response from server: -1 >> at org.apache.openejb.client.JNDIContext.lookup(JNDIContext.java:277) >> at javax.naming.InitialContext.lookup(InitialContext.java:392) >> ... >> >> The geronimo.log server-side shows, >> >> java.io.IOException: Unexpected byte 128 >> at >> org.apache.openejb.server.ejbd.KeepAliveServer$Session.service(KeepAliveServer.java:221) >> at >> org.apache.openejb.server.ejbd.KeepAliveServer.service(KeepAliveServer.java:233) >> at org.apache.openejb.server.ejbd.EjbServer.service(EjbServer.java:66) >> ... >> >> When I dig into the OpenEjb server code, ServerDaemon.java, it appears to >> need a "secure" property to be set to true. When I debug the code, >> ServerDaemon.java configures the socket listener when the GBean starts, >> then never again, so I'm not sure how this is supposed to work. Using >> contextProperties.put("ejbd.secure", "true") on the client side has no >> effect. And I can't find a way to set the 'secure' attribute in >> Geronimo's config.xml. Geronimo fails to start, complaining that >> 'secure' is unrecognized when I add it as an attribute to >> EJBNetworkService. >> >> One of the links above mentions doing >> properties.setProperty("ejbd.secure", "true") on the server side, but >> where/how would I do that? >> >> What am I missing? >> >> Any help would be appreciated. >> >> > > -- View this message in context: http://www.nabble.com/OpenEJB-over-SSL-tp26034601p26063931.html Sent from the OpenEJB User mailing list archive at Nabble.com.
