wildfly 11 rmi over http

[crazycradd]

I have moved my app to wildfly 11 and all works well.

I now want to move the client to connect over pure http

I read a couple of posts and this appears to work but I now get a class not found exception

The original connection was made like this and I can still use this in wildfly 11

contextProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");

contextProps.put(Context.PROVIDER_URL,"http-remoting://ghvh01:4160");

I have altered the code to use

contextProps.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");

contextProps.put(Context.PROVIDER_URL,"http://ghvh01:4160/wildfly-services");

The remote ejb is looked up but when I try to execute a method I get the following

com.cedar.cp.api.base.CPException: com.cedar.cp.api.base.CPPrincipal from [Module "org.wildfly.extension.io" from local module loader @146044d7 (finder: local module finder @1e9e725a (roots: /data/jboss/ni/4160/JBoss_AS11/modules,/data/jboss/ni/4160/JBoss_AS11/modules/system/layers/base))]

The server side code does not appear to be invoked

[mchoma]

And does "pure http" works for you in previous configuration? In wildfly 11 there was introduced remote+http protocol [1]  Try this.

Also do you use wildfly 11 client dependencies?

[1] [WFCORE-296] Switch URI scheme from remoting:// http-remoting:// https-remoting:// to remote:// remote+http:// and remot…

[2] Application Client Migration - Latest WildFly Documentation - Project Documentation Editor

[crazycradd]

I have altered the url to use remote+http and the app now connects but im unsure if this is using pure http or not.

The connection url being used is remote+http://ghvh01:4160/wildfly-services I'll have to try and setup a proxy server to test it further.

In as10 the remote-http://ghvh01:4160 upgraded its connection to be a socket connection.

I'll test and update you later

[mchoma]

Ah, I see now you probably mean [1]. Have you http-invoker configured correctly?

And this Class not found exception is from client side? CPPrincipal seems as application class.

[1]  EJB over HTTP - Latest WildFly Documentation - Project Documentation Editor

[crazycradd]

I currently have the client app working using the new initial context and the either of the following urls

http-remote://ghvh01:4160

or

remote+http://ghvh01:4160

The app also works if I use the old initial context and the first urls nothing else is being altered so I would not expect and classnotfound exception.

If I turn on my firewall and go via a proxy the remote+http://ghvh01:4160/wildfly-services fails to connect I set the -Dhttp.proxyHost and -Dhttp.proxyPort values

From what I read the http-invoker is set up correctly by default and I have not altered the config.

[mchoma]

Could you redefine the problem again? So you are trying to achieve [1], what happens when you try so.

[1]  EJB over HTTP - Latest WildFly Documentation - Project Documentation Editor

[crazycradd]

I have a swing based application that needs to connect to the server via RMI this has worked against AS8 and AS10 but needs to create a socket to communicate.

When I read this EJB over HTTP - Latest WildFly Documentation - Project Documentation Editor I decided to move to AS11 and see if this worked.

As I said I can lookup the ejb via the http url but I cannot invoke it without getting the classpath error and the remote +http does not seem to use the proxy

[jaikiran]

The remote ejb is looked up but when I try to execute a method I get the following

com.cedar.cp.api.base.CPException: com.cedar.cp.api.base.CPPrincipal from [Module "org.wildfly.extension.io" from local module loader @146044d7 (finder: local module finder @1e9e725a (roots: /data/jboss/ni/4160/JBoss_AS11/modules,/data/jboss/ni/4160/JBoss_AS11/modules/system/layers/base))]

Can you post the complete exception stacktrace? Looking at that log message it appears that it's looking for that class in the wrong module, which either is a configuration issue or a genuine bug. The complete stacktrace might give us some hint.

[crazycradd]

Here is the full stack trace

Collaborative Planning Error:

Internal processing error

Stack Trace:

com.cedar.cp.api.base.CPException: com.cedar.cp.api.base.CPPrincipal from [Module "org.wildfly.extension.io" from local module loader @146044d7 (finder: local module finder @1e9e725a (roots: /data/jboss/ni/4160/JBoss_AS11/modules,/data/jboss/ni/4160/JBoss_AS11/modules/system/layers/base))]

    at com.cedar.cp.ejb.api.base.AbstractSession.unravelException(AbstractSession.java:121)

    at com.cedar.cp.ejb.api.logon.LogonServer.authenticateUser(LogonServer.java:130)

    at com.cedar.cp.impl.base.CPConnectionImpl.<init>(CPConnectionImpl.java:237)

    at com.cedar.cp.impl.base.ConnectionFactory.getConnection(ConnectionFactory.java:16)

    at com.cedar.cp.api.base.DriverManager.getConnection(DriverManager.java:71)

    at com.cedar.cp.api.base.DriverManager.getConnection(DriverManager.java:45)

    at com.cedar.cp.tc.main.MainFrame$1.login(MainFrame.java:97)

    at com.cedar.cp.tc.main.MainFrame.openConnection(MainFrame.java:952)

    at com.cedar.cp.tc.main.MainFrame.splashInit(MainFrame.java:129)

    at com.cedar.cp.tc.main.MainFrame$2.run(MainFrame.java:151)

    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)

    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)

    at java.awt.EventQueue.access$500(EventQueue.java:97)

    at java.awt.EventQueue$3.run(EventQueue.java:709)

    at java.awt.EventQueue$3.run(EventQueue.java:703)

    at java.security.AccessController.doPrivileged(Native Method)

    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)

    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)

    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)

    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)

    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)

    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)

    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)

    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

Caused by: java.lang.ClassNotFoundException: com.cedar.cp.api.base.CPPrincipal from [Module "org.wildfly.extension.io" from local module loader @146044d7 (finder: local module finder @1e9e725a (roots: /data/jboss/ni/4160/JBoss_AS11/modules,/data/jboss/ni/4160/JBoss_AS11/modules/system/layers/base))]

    at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)

    at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:412)

    at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:400)

    at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)

    at java.lang.Class.forName0(Native Method)

    at java.lang.Class.forName(Class.java:344)

    at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:123)

    at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:104)

    at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:1025)

    at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1354)

    at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:275)

    at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:208)

    at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)

    at org.wildfly.httpclient.ejb.HttpInvocationHandler$1.getRequestContent(HttpInvocationHandler.java:169)

    at org.jboss.as.ejb3.remote.AssociationImpl.receiveInvocationRequest(AssociationImpl.java:126)

    at org.wildfly.httpclient.ejb.HttpInvocationHandler.lambda$handleInternal$0(HttpInvocationHandler.java:130)

    at org.wildfly.httpclient.ejb.HttpInvocationHandler$$Lambda$939/1601025192.run(Unknown Source)

    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

    at java.lang.Thread.run(Thread.java:745)

[jaikiran]

A quick look at the relevant classes in that stacktrace does seem to indicate this is probably a bug in wildfly-http-client library. Is there a simple application that can you attach (preferably a source that can be built), which reproduces this issue?

[jaikiran]

jaikiran wrote:

Is there a simple application that can you attach (preferably a source that can be built), which reproduces this issue?

Never mind, I was able to reproduce this in a simple testcase within the WildFly project. I'll send a PR with a fix.

[jaikiran]

@crazycradd, can you please file a JIRA in the WildFly project here - JBoss Issue Tracker  explaining this issue and pointing to this discussion? That way, the issue gets reported by your name. I'll then go ahead and propose a PR containing the fix.

[crazycradd]

raised as [WFLY-9573] problem executing remote ejb call - JBoss Issue Tracker

[crazycradd]

This looks like a client side fix will I be able to get a new version of wildfly-client-all from maven or will I have to build this locally

[jaikiran]

peter craddock wrote:

This looks like a client side fix

Actually no. The wildfly-http-client library gets used by the WildFly server on the server side and in this case it tries to unmarshal the invocation on the server side and fails to do so. If you do have the ability to update/patch your WildFly 11 installation, then you could actually update the library to a newer version which contains the fix, once the PR is merged and a new version of the library released.