Many people have asked for help with this error:
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint(Ljava/lang/String;Lorg/xnio/OptionMap;)Lorg/jboss/remoting3/Endpoint;]
at
org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:51)
at
org.jboss.naming.remote.client.InitialContextFactory.getInitialContext(InitialContextFactory.java:152)
at
javax.naming.spi.NamingManager.getInitialContext(Unknown Source)
...
But no request I can find ever provides a conclusive answer. Just suggestions to tinker with jars.
I believe that’s because there’s an inconsistency in the structure of Jboss interfaces. Can anyone confirm or correct that?
Here’s my code that throws the above error:
final private Properties env = new Properties() {
{put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
put(Context.PROVIDER_URL, "http-remoting://localhost:9990");
put(Context.SECURITY_PRINCIPAL, "myID");
put(Context.SECURITY_CREDENTIALS, "myPassword");
put("jboss.naming.client.ejb.context", true);
}
};
/****************************************************
* myID & myPassword open the Admin GUI for wildfly *
* on localhost:9990 *
****************************************************/
Context ctx = new InitialContext(this.env);
To determine the required jars I removed all jars from the Build path. Then I ran my program till all ClassNotFoundException were gone.
First Error
java.lang.ClassNotFoundException:
org.jboss.naming.remote.client.InitialContextFactory]
Added jboss-remote-naming-1.0.7.final.jar to class path
Second Error
java.lang.NoClassDefFoundError:
org/jboss/logging/Logger
Added jboss-logging.jar
Third Error
java.lang.NoClassDefFoundError:
org/xnio/Options
Added xnio-api-3.0.7.ga.jar
Fourth Error
java.lang.NoClassDefFoundError:
org/jboss/remoting3/spi/ConnectionProviderFactory
Added jboss-remoting-3.jar
Fifth Error
java.lang.NoClassDefFoundError:
org/jboss/ejb/client/EJBClientContextIdentifier
Added jboss-ejb-client-1.0.19.final.jar
FINAL AND FATAL ERROR (Note: All NoClassDefFoundError have been cleared)
java.lang.NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint(Ljava/lang/String;Lorg/xnio/OptionMap;)Lorg/jboss/remoting3/Endpoint;]
Using Eclipse’s Project Explorer I verified:
a. jboss-remoting3.jar has the org.jboss.remoting3.Remoting Class.
b. That Remoting Class has this Method:
public Endpoint createEndpoint (String, Executor, OptionMap)
Note it calls for 3 parameters.
BUT the FINAL FATAL ERROR above calls for
public Endpoint createEndpoint (String, OptionMap)
Note: it calls for 2 parameters. Hence the NoSuchMethodError.
Looking at the top lines in the stack trace, I guess org.jboss.naming.remote.client.InitialContextFactory.getInitialContext() is trying to call org.jboss.remoting3.Remoting.createEndpoint() using 2 parameters, but org.jboss.remoting3.Remoting only defines createEndpoint() with a 3-paramater signature.
Is that supposed to even be possible? A jar that says it has the org.jboss.remoting3 package whose Remoting class has a single createEndpoint() method with a 3-parameter signature, and another jar that says it has the org.jboss.remoting3 package whose Remoting class has another createEndpoint() method with a 2-parameter signature?
HELP!
I mean do I need to look through every org.jboss.remoting3 package to find one whose Remoting class has a 2 parameter createEnpoint() method?
Or am I missing something important.
I mean this does explain how many questions have been posted about this error:
javax.naming.NamingException: Failed to create remoting connection [Root exception is java.lang.NoSuchMethodError: org.jboss.remoting3.Remoting.createEndpoint(Ljava/lang/String;Lorg/xnio/OptionMap;)Lorg/jboss/remoting3/Endpoint;]
And explain why there is never a conclusive explanation or solution other than fiddling with jars and build path.
I mean getting an InitialContext from WildFly running on the same PC as the Java program should be a trivial process. But it hasn’t been. Maybe it's because of inconsistencies in the API.
