Missing org.jnp.server.NamingServer_Stub

[dimitris]

We've introduced reverse compatibility tests (AS5 client accessing 4.2.x server) and one of the problems I'm seeing is the client AS5 side missing the org.jnp.server.NamingServer_Stub class.

It seem after jboss-naming was broken out we don't produce this class with RMIC anymore.

Why is that?

http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-4.2.x-CompatibilityMatrix/lastBuild/testReport/org.jboss.test.compatibility.test.matrix/MatrixTestContainer(bmp_5_0_x)/org_jboss_test_bmp_test_SmallCacheBmpUnitTestCase__testBMP/

javax.naming.CommunicationException: Could not obtain connection to any of these urls: localhost:1099 and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is java.lang.ClassNotFoundException: org.jnp.server.NamingServer_Stub (no security manager: RMI class loader disabled)]]
 at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1727)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:680)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:673)
 at javax.naming.InitialContext.lookup(InitialContext.java:351)
 at org.jboss.test.bmp.test.SmallCacheBmpUnitTestCase.testBMP(SmallCacheBmpUnitTestCase.java:46)
 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
 at junit.extensions.TestSetup.run(TestSetup.java:23)
 at org.jboss.test.compatibility.test.matrix.MatrixTestContainer$TestProxy.run(MatrixTestContainer.java:185)
 at org.jboss.test.compatibility.test.matrix.MatrixTestContainer$TestSuiteProxy.run(MatrixTestContainer.java:85)
Caused by: javax.naming.CommunicationException: Failed to connect to server localhost:1099 [Root exception is java.lang.ClassNotFoundException: org.jnp.server.NamingServer_Stub (no security manager: RMI class loader disabled)]
 at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:311)
 at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1698)
 ... 29 more
Caused by: java.lang.ClassNotFoundException: org.jnp.server.NamingServer_Stub (no security manager: RMI class loader disabled)
 at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371)
 at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
 at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
 at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
 at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
 at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
 at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
 at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:290)

[starksm64]

I thought this was no longer needed since jdk support dynamic proxies. Probably the classpath does not have the org.jnp.server.NamingServer. What jars are in the test classpath?

"java.rmi.server.UnicastRemoteObject javadoc" wrote:

For the constructors and static exportObject methods below, the stub for a remote object being exported is obtained as follows:

* If the remote object is exported using the UnicastRemoteObject.exportObject(Remote) method, a stub class (typically pregenerated from the remote object's class using the rmic tool) is loaded and an instance of that stub class is constructed as follows.
o A "root class" is determined as follows: if the remote object's class directly implements an interface that extends Remote, then the remote object's class is the root class; otherwise, the root class is the most derived superclass of the remote object's class that directly implements an interface that extends Remote.
o The name of the stub class to load is determined by concatenating the binary name of the root class with the suffix "_Stub".
o The stub class is loaded by name using the class loader of the root class. The stub class must extend RemoteStub and must have a public constructor that has one parameter, of type RemoteRef.
o Finally, an instance of the stub class is constructed with a RemoteRef.
* If the appropriate stub class could not be found, or the stub class could not be loaded, or a problem occurs creating the stub instance, a StubNotFoundException is thrown.

* For all other means of exporting:

o If the remote object's stub class (as defined above) could not be loaded or the system property java.rmi.server.ignoreStubClasses is set to "true" (case insensitive), a Proxy instance is constructed with the following properties:
+ The proxy's class is defined by the class loader of the remote object's class.
+ The proxy implements all the remote interfaces implemented by the remote object's class.
+ The proxy's invocation handler is a RemoteObjectInvocationHandler instance constructed with a RemoteRef.
+ If the proxy could not be created, a StubNotFoundException will be thrown.

o Otherwise, an instance of the remote object's stub class (as described above) is used as the stub.

[dimitris]

It uses the client/jnp-client.jar that contains no org.jnp.server classes:

[dimitris]

The client pom.xml includes only

<include name="org/jnp/interfaces/**" />
 <include name="org/jboss/naming/**" />

[dimitris]

I've tryied adding org.jnp.server.NamingServer.class in jnp-client.jar but the error remaims the same:

Caused by: java.lang.ClassNotFoundException: org.jnp.server.NamingServer_Stub (no security manager: RMI class loader disabled)
 at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:371)
 at sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:165)
 at java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:620)
 at java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:247)
 at sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:197)
 at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1544)
 at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466)
 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699)
 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305)
 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
 at java.rmi.MarshalledObject.get(MarshalledObject.java:135)
 at org.jnp.interfaces.NamingContext.getServer(NamingContext.java:290)

[adrian.brock]

It is using the dynamic proxy which you can see from the logging
when it binds the stub:

2008-11-21 13:06:31,807 DEBUG [org.jboss.naming.Naming] (main) Creating NamingServer stub, theServer=MBeanProxyExt[jboss:service=NamingBeanImpl],rmiPort=1098,clientSoc
ketFactory=null,serverSocketFactory=org.jboss.net.sockets.DefaultSocketFactory@e048aaa4[bindAddress=/127.0.0.1]
2008-11-21 13:06:32,082 DEBUG [org.jboss.naming.Naming] (main) NamingServer stub: Proxy[Naming,RemoteObjectInvocationHandler[UnicastRef2 [liveRef: [endpoint:[127.0.0.1
:1098,org.jboss.net.sockets.DefaultSocketFactory@e048aaa4[bindAddress=/127.0.0.1]](local),objID:[0]]]]]

My guess is that it can't deserialze the proxy because there is a new interface not in 4.2.x
i.e. org.jnp.interfaces.NamingEvents
so it is falling back to trying to use the stub?

Which way around is this test? It's not clear from the above description.
The old stub should be available in 4.2.x without the new interface methods?

[adrian.brock]

Which way around is this test? It's not clear from the above description.
The old stub should be available in 4.2.x without the new interface methods?

I think this is 5.0.x lookup 4.2.x isn't it?

If you look at 4.2.x the server isn't using the dynamic proxy
because the stub exists on the server.

2008-11-21 13:16:46,000 DEBUG [org.jboss.naming.Naming] NamingServer stub: NamingServer_Stub[UnicastRef2 [liveRef: [endpoint:[127.0.0.1:1098,org.jboss.net.sockets.Defa
ultSocketFactory@e048aaa4[bindAddress=/127.0.0.1]](local),objID:[0]]]]

So if the server used the stub class then the client must also do the same.

Can you try getting jboss-4.2.x to ignore stub classes and always use dynamic proxies?
i.e. start jboss-4.2.x with -Djava.rmi.server.ignoreStubClasses=true

[adrian.brock]

I've tryied adding org.jnp.server.NamingServer.class in jnp-client.jar but the error remaims the same:

If my guesses above are true, then JBoss5 needs the stub class in the server jar
if it wants to talk to 4.2.x jndi (and stub classes haven't been disabled for it).

[adrian.brock]

Can you try getting jboss-4.2.x to ignore stub classes and always use dynamic proxies?
i.e. start jboss-4.2.x with -Djava.rmi.server.ignoreStubClasses=true

If I do that, then a 5.0.x -> 4.2.x lookup works.
Here's a simple jsp page (you'll need to change the provider url)

<%@page contentType="text/html"
 import="java.util.Properties,javax.naming.*"
%>

<%
 Properties props = new Properties();
 props.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
 props.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces");
 props.put("java.naming.provider.url", "127.0.0.1:1099");
 InitialContext ctx = new InitialContext(props);
 Object obj = ctx.lookup("jmx/rmi/RMIAdaptor");
%>
<body>
 Got <%= obj %> of type <%= obj.getClass() %>
<body>
</body>
</html>

But a 4.2.x -> 5.0.x lookup fails because of the new interface:

javax.naming.CommunicationException: Failed to connect to server 127.0.0.1:1099 [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingEvents (no security manager: RMI class loader disabled)]
 org.jnp.interfaces.NamingContext.getServer(NamingContext.java:274)
 org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1533)
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:634)
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
 javax.naming.InitialContext.lookup(InitialContext.java:351)

[adrian.brock]

But a 4.2.x -> 5.0.x lookup fails because of the new interface:

javax.naming.CommunicationException: Failed to connect to server 127.0.0.1:1099 [Root exception is java.lang.ClassNotFoundException: org.jnp.interfaces.NamingEvents (no security manager: RMI class loader disabled)]
 org.jnp.interfaces.NamingContext.getServer(NamingContext.java:274)
 org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1533)
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:634)
 org.jnp.interfaces.NamingContext.lookup(NamingContext.java:627)
 javax.naming.InitialContext.lookup(InitialContext.java:351)

Adding that class in a jar to server/xxx/lib in 4.2.x allows the lookup to work.

[dimitris]

Sorry, I've just seen the replies. The test involves 5.0.x client accessing 4.2.x server. It's the last addition in the compatibility-matrix of Branch_4_2.

The other way round (4.2.x client accessing 5.0.x server) is working.

[adrian.brock]

The other way round (4.2.x client accessing 5.0.x server) is working.

Not for me it isn't. ;-)
See above.

[adrian.brock]

The other way round (4.2.x client accessing 5.0.x server) is working.

Not for me it isn't. ;-)
See above.

But if I compile the NamingServer_stub for JBoss5 and add it the
server/xxx/lib
then both are happy.

That's because the stub classes are different (not the same interfaces)
in the two different versions.

So the short answer is that dynamic proxies can't work if you change the
interfaces of your Remote object. ;-)

[starksm64]

Are you going to do a new naming release or do you want me to?

[adrian.brock]

Are you going to do a new naming release or do you want me to?

How do you get maven to do the rmic?

I tried using the maven rmic plugin, but it puts the stubs in target/rmi-classes
and then doesn't include them in the jar.

It looks like maven's opinion is that stubs should go in a seperate jar???? ;-)
http://mojo.codehaus.org/rmic-maven-plugin/package-mojo.html