Please help with @EJB not resolving problem on WildFly 26.1.2

254 views
Skip to first unread message

Norval Hope

unread,
Dec 5, 2022, 11:33:17 AM12/5/22
to WildFly
Hi All,

This is my first post to this group, and hoping some kind knowledgeable person may be able to offer some insights into a weird problem I'm having in the annotation resolving space :-)

I have a TestBean with a Local interface in the normal pattern, and despite the fact that I get WELD failures when I present a wrong lookup= path in the references below, none of the annotations initialise their fields at bean construction time:

--- referencing class (class in .war file)
    private static final String full_path = "java:global/consol/consol-ejb/TestBean!au.com.hubbub.consol.beans.person.ejb.TestBeanLocal";
   
    //@EJB(lookup = "java:app/consolWebDev/TestBean")
    @Resource(lookup = full_path)
    private TestBean testBean1;
   
    //@Resource(lookup = "java:global/consol/consolWebDev/TestBean")
    //@Resource(lookup = "java:global/consol/consolWebDev/TestBean!au.com.hubbub.consol.web.user.TestBean")
    private TestBean testBean2 = (TestBean)forceLookUp(full_path);

    @EJB(lookup = full_path)
    private TestBean testBean3;
   
    //@EJB
    //private TestBean testBean;
   
    private @EJB TestBeanLocal testBean;
   
    //@Inject
    private @Autowired @Lazy PersonLocal personLocal;
   
    private @EJB PersonEJB personEJB;
    /*
    @Resource(lookup = "java:global/consol/consol-ejb/PersonEJB")
    private PersonLocal personLocal;
    */

    private @Inject PersonBean personBean;
   

    public static Object forceLookUp(String jndiName) {
        final String name  = jndiName;

        try {
            final Context ctx = new InitialContext(null);
            final Object home = ctx.lookup(name);
           
            try {
                ctx.close();
            } catch (NamingException e) {
                // Who cares - if the context doesn't know how to close itself - we certainly don't.
            }
           
            return home;
           
        } catch (NamingException e) {
            throw new RuntimeException("Could not locate EJB with name " + name, e);
        }
    }
   
    public String lookupUser(final String userId) {
        TestBean b = testBean2;
        log.warn("testBean=" + testBean + ",testBean1=" + testBean1 + ",testBean2=" + testBean2 + ",testBean3=" + testBean3
                + ",personEJB=" + personEJB);
        log.warn("test=" + b.test());
       
        return b.test();
        /*
        if (StringUtils.isBlank(userId)) { return null; }

        try {
            return personEJB.findByUserId(userId).getModel();
        } catch (final FinderException e) {
            return null;
        }
        */
    }

---
package au.com.hubbub.consol.beans.person.ejb;

import javax.ejb.Local;
import javax.ejb.Stateful;
import javax.ejb.Stateless;
import javax.inject.Named;

@Local
public interface TestBeanLocal {

    public String test();
}
----
package au.com.hubbub.consol.beans.person.ejb;

import javax.ejb.Local;
import javax.ejb.Stateful;
import javax.ejb.Stateless;
import javax.inject.Named;

@Stateless
@Named
public class TestBean implements TestBeanLocal {

    public TestBean() {
    }

    public String test() {
        return "tested";
    }
}   

Despite cranking up logging to the max (at least for packages I know about) I have not been able to get any of the annotations to resolve,  but the direct JNDI lookup works perfectly:
     private TestBean testBean2 = (TestBean)forceLookUp(full_path);

The relevant log messages from the WildFly log are these:
22:19:34,334 DEBUG [org.jboss.as.ee] (MSC service thread 1-4) Configuring component class: au.com.hubbub.consol.beans.person.ejb.TestBean named TestBean
22:19:36,960 DEBUG [org.jboss.as.ejb3] (MSC service thread 1-8) Using pool config StrictMaxPoolConfig{name=slsb-strict-max-pool, maxPoolSize=128, timeoutUnit=MINUTES, timeout=5} to create pool for Stateless EJB TestBean
22:23:26,881 DEBUG [org.jboss.as.jpa] (MSC service thread 1-6) Adding dependency on PU service service jboss.persistenceunit."consol.ear#ConsolPersistenceUnit" for component au.com.hubbub.consol.beans.person.ejb.TestBean
22:23:30,846 INFO  [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'TestBean' in deployment unit 'subdeployment "consol-ejb" of deployment "consol.ear"' are as follows:
    java:global/consol/consol-ejb/TestBean!au.com.hubbub.consol.beans.person.ejb.TestBeanLocal
    java:app/consol-ejb/TestBean!au.com.hubbub.consol.beans.person.ejb.TestBeanLocal
    java:module/TestBean!au.com.hubbub.consol.beans.person.ejb.TestBeanLocal
    java:global/consol/consol-ejb/TestBean
    java:app/consol-ejb/TestBean
    java:module/TestBean
22:23:33,260 DEBUG [org.jboss.as.ee] (MSC service thread 1-6) Configuring component class: au.com.hubbub.consol.beans.person.ejb.TestBean named TestBean
22:23:34,567 DEBUG [org.jboss.as.ejb3] (MSC service thread 1-5) Using pool config StrictMaxPoolConfig{name=slsb-strict-max-pool, maxPoolSize=128, timeoutUnit=MINUTES, timeout=5} to create pool for Stateless EJB TestBean
22:24:30,222 WARN  [au.com.hubbub.consol.web.user.LoginAction] (default task-1) testBean=null,testBean1=null,testBean2=Proxy for view class: au.com.hubbub.consol.beans.person.ejb.TestBeanLocal of EJB: TestBean,testBean3=null,personEJB=null

which to me look very promising except that the annotations do not ultimate resolve. I am migrating a very old application  from weblogic 10.3 which uses Spring heavily but I haven't seen any classloading issues or annotation class clashes that explain my woes.

Is there any logging I should crank up further in the bits of WildFly library code that look up the annotation values after they have apparently been successfully registered?

The otherwise old and complex application works fine once started, but is using the explicit "lookup from InitialContext" approach everywhere, so using a nice plain @EJB would be sooo much better and more modern.

Any help / thoughts greatly appreciated.

Thanks!
Reply all
Reply to author
Forward
0 new messages