Wildfly 10 jndi issue

[kimba]

Hi.

I've been struggling with my setup for a while, and wanted to ask for help
I have two Java applications running on two separate virtual machines, deployed on Wildfly 10. I am working on modernizing my project and currently rewriting it to support java8 and wildfly 10
Currently i have problem with JNDI lookup:

Here is piece of code that creates InitialContext

private Context createContext(String provider) throws NamingException{

  Properties properties = new Properties();
   properties.put(Context.URL_PKG_PREFIXES, "org.jboss.ejb.client.naming");
   properties.put(Context.INITIAL_CONTEXT_FACTORY, InitialContextFactory.class.getName());
   properties.put(Context.PROVIDER_URL, "http-remoting://" + provider + ":80");
   return new InitialContext(properties);
}

public <T> T getRemote (Class<T> remote, String providerUrl, String jndiName, String appName, String moduleName) throws NamingException {

  final Context context = createContext(providerUrl);
  final String viewClassName = remote.getName();
   return remote.cast( context.lookup(  "/" + appName + "/" + moduleName + "/" + jndiName + "!" + viewClassName) );
}

In the moment I make lookup, i receive exception

java.lang.LinkageError: loader constraint violation: when resolving method "org.jboss.ejb.client.EJBClientContext.registerConnection(Lorg/jboss/remoting3/Connection;)V" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/jboss/naming/remote/client/ejb/RemoteNamingStoreEJBClientHandler, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jboss/ejb/client/EJBClientContext, have different Class objects for the type org/jboss/remoting3/Connection used in the signature

    at org.jboss.naming.remote.client.ejb.RemoteNamingStoreEJBClientHandler.associate(RemoteNamingStoreEJBClientHandler.java:78)

    at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.<init>(RemoteNamingStoreV1.java:71)

    at org.jboss.naming.remote.protocol.v1.VersionOne.getRemoteNamingStore(VersionOne.java:50)

    at org.jboss.naming.remote.protocol.Versions.getRemoteNamingStore(Versions.java:55)

    at org.jboss.naming.remote.client.RemoteContextFactory.createVersionedStore(RemoteContextFactory.java:73)

    at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:202)

    at org.jboss.naming.remote.client.HaRemoteNamingStore.namingStore(HaRemoteNamingStore.java:149)

    at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:130)

    at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:272)

    at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)

    at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)

    at javax.naming.InitialContext.lookup(InitialContext.java:417)

    at javax.naming.InitialContext.lookup(InitialContext.java:417)

My list of dependencies for application contains xnio-nio dependency,that can potentially cause this (without it i received java.lang.IllegalArgumentException: XNIO001001: No XNIO provider found):
<dependency>
  <groupId>org.jboss.xnio</groupId>
  <artifactId>xnio-nio</artifactId>
  <version>3.4.0.Final</version>
</dependency>

I don't have any other property files that can cause this. I can add standalone-full, but i don't think it can cause this error.

[dmlloyd]

This is likely a packaging problem.  Go through each of your dependencies in the POM file and make sure that if they come from WildFly, the scope is set to "provided".

[kimba]

I decided that i'm trying to force outdated solution and moved to add http-remoting instead