Wildfly 10.1 JNDI JNP issue

[mmuthu]

We have been using JBOSS 5.1 and my clients are accessing sending messages to the configured queue and topic using JNDI JNP. How to get that working in Wildfly 10.1.

jndiConfigDetails.put(keyNamingfactory, "org.jnp.interfaces.NamingContextFactory");

jndiConfigDetails.put(keyNamingURLPackage, "org.jboss.naming:org.jnp.interfaces");

jndiConfigDetails.put(keyNamingURL, "jnp://127.0.0.1:1099");

How to get those name binding working. I'm able to get those topic and queues bound with the messaging-activemq. I'm also able to post messages using WILDFLY_REMOTING_URL. But this will require changes in client program along with few JAR upgrade. We are not ready to make those changes. How to achieve backward compatibility for my client.

Thanks for your time...

[gir489]

JNDI Reference - WildFly 8 - Project Documentation Editor

Remote JNDI

WildFly supports two different types of remote JNDI. The old jnp based JNDI implementation used in JBoss AS versions prior to 7.x is no longer supported.

[mmuthu]

As an alternate is there a way to run those old clients which runs in Java6 against this new messaging which runs in Wildfly 10.1. Yes, I understand we need to get latest JAR using "wildfly-jms-client-bom". But they won't work because they will need Java8. Any options suggestion?

Thanks !

[gir489]

I think you answered your own question there, but you're confused on the semantics, so I'll clarify.

Gone are the days of webserver dependencies. You are NEVER supposed to include a wildfly/tomcat/jetty JAR in your application as a dependency. That JAR you're referring to is compiled with Java 8, because Wildfly 10.1 is meant to run on Java 8. It will be irrelevant to the environment your app is trying to run in. In your case, Java 6.

You're supposed to depend on the core Java API as much as possible. Such as javax.jms. Wildfly will then intercept the javax JMS API calls and implement them accordingly. I really feel the wild-west Java 5/Java 6 era of C/C++ programmers using hard dependencies has left a bad taste in the Java flavor as a whole, because dealing with these apps has become a nightmare. Oracle is trying to rid itself of this plague by forcing EE-based apps (in our case, Wildfy) to adhere to the EE spec as much as possible. This way, it will ensure portability and true cross platform support, as Java was truly intended.

Depending on how tightly coupled you are to JBoss' JNP will determine how hard it is to port to JMS. But honestly it will be worth it, because going forward, all webservers will implement and support anything in the core Java API. This has not changed since Java 1.0. The biggest problem I'm seeing today is cutting out the cancer of Sun JARs that weren't supposed to be packed with the runtime in the first place.