I'm trying to port an EJB 2.1 application that was running happily under JBoss 6.0.0.Final to WildFly 12.0. This does not use EJB 3 annotations, but has a full deployment descriptor.
The EAR deploys without error, but when I try to look up the Remote EJB from a client, the lookup() returns an org.wildfly.naming.client.store.RelativeContext object that causes a ClassCastException when I try to cast it to the Remote EJB class, either with PortableRemoteObject.narrow() or with the EJB 3 direct cast.
I've googled this, and all of the hits seem to deal with clashes between Classloaders for WARs and EJBs, but that's not the case here. This is a vanilla WildFly install running standalone-full with no changes and nothing but the EAR containing the EJB deployed.
Following the docs, I changed jndi.properties to use:
where previously it had used port 1099 and a JBoss InitialContextFactory.
The original lookup string was <ear-name>/<bean name>/remote. That complained about no provider for URI: null, so following the quickstart I switched this to ear:<ear-name>/<bean name>/remote, and that got me to the ClassCastException. The quickstart examples added !<full class name>, so I tried that with the same result.
The examples also inserted the EJB jar name, but when I tried that the lookup itself failed saying the name couldn't be found.
The deployment issues the messages:
[0m [0m13:37:20,809 INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-6) WFLYEJB0473: JNDI bindings for session bean named 'DBUtDVDSessionBean' in deployment unit 'subdeployment "dvd-ejb-1.0-SNAPSHOT.jar" of deployment "dvd-ear.ear"' are as follows:
Looking through the docs, it seems that there are now two ways to do lookups, one that does the classic JNDI lookup on the server and one that builds a local proxy from extra information in the lookup string and only binds to the EJB when the proxy is used, but it's not clear to me which is which. The other one uses port 4447 and "remote." properties, but nmap shows port 4447 to be closed, so I assumed port 8080 was now the default.
So I have two questions.
The first is why and under what circumstances a JNDI lookup would return a RelativeContext which can't possibly work. I looked at the RelativeContext source, but it only has a few public methods that don't seem to have anything to do with proxying an EJB.
The second is can someone point me to the correct jndi.properties and lookup string format for WildFly if mine aren't correct ? When I originally wrote this application, I took great care to use as few JBoss-specific features as possible so as to ensure portability from one AS to another, so while I understand that the new delayed binding is more efficient from a network standpoint, if it involves WildFly-specific features I'd rather stay with the classic JNDI model.