-
1. Re: Wildfly 10.1 JNDI JNP issue
gir489 Sep 6, 2017 10:38 AM (in response to mmuthu)1 of 1 people found this helpfulJNDI 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.
-
2. Re: Wildfly 10.1 JNDI JNP issue
mmuthu Sep 7, 2017 2:56 AM (in response to gir489)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 !
-
3. Re: Wildfly 10.1 JNDI JNP issue
gir489 Sep 7, 2017 12:49 PM (in response to mmuthu)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.