GF: Fail to lookup EJB that is declared in war module of an EAR

[glassfishrobot]

When declare EJB to be JAX-RS endpoint inside war module that included in EAR like this:

@Stateless
@Path("/user")
@Produces(MediaType.APPLICATION_JSON)
public class UsersResource {
...

Name of the war module is "op-client" I got following exception in the logs:

[2014-10-20T18:56:53.226+0200] [glassfish 4.1] [WARNING] [] [org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider] [tid: _ThreadID=31 _ThreadName=http-listener-1(5)] [timeMillis: 1413824213226] [levelValue: 900] [[
  An instance of EJB class, com.mycompany.opclient.rest.UsersResource, could not be looked up using simple form name. Attempting to look up using the fully-qualified form name.
javax.naming.NamingException: Lookup failed for 'java:app/someothermodule/UsersResource' in SerialContext[myEnv={java.naming.factory.initial=com.sun.enterprise.naming.impl.SerialInitContextFactory, java.naming.factory.state=com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl, java.naming.factory.url.pkgs=com.sun.enterprise.naming} [Root exception is javax.naming.NameNotFoundException: No object bound to name java:app/someothermodule/UsersResource]
    at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:491)
    at com.sun.enterprise.naming.impl.SerialContext.lookup(SerialContext.java:438)
    at javax.naming.InitialContext.lookup(InitialContext.java:411)
    at javax.naming.InitialContext.lookup(InitialContext.java:411)
    at org.glassfish.jersey.gf.ejb.internal.EjbComponentProvider.lookupSimpleForm(EjbComponentProvider.java:378)
....

Note that lookup is complains about "someothermodule" not "op-client". Earlier in the logs though there is following message:

[2014-10-20T18:08:29.484+0200] [glassfish 4.1] [INFO] [AS-EJB-00054] [javax.enterprise.ejb.container] [tid: _ThreadID=44 _ThreadName=admin-listener(4)] [timeMillis: 1413824909484] [levelValue: 800] [[
  Portable JNDI names for EJB UsersResource: [java:global/earmodule/op-client/UsersResource, java:global/earmodule/op-client/UsersResource!com.mycompany.opclient.rest.UsersResource]]]

Which means that bean was successfully discovered and registered and should be available for lookup. Evaluating expression with proper name for lookup at breakpoint in EjbComponentProvider confirms that. Digging deeper into the problem I've found that patch that was made to fix this issue (325a2f214e093859d41d81f9f06652c169a03aa4) introduced following code in registerEjbInterceptor method of EjbComponentProvider:

private void registerEjbInterceptor() {
        try {
            final Object interceptor = new EjbComponentInterceptor(locator);
            initialContext = getInitialContext();
            final EjbContainerUtil ejbUtil = EjbContainerUtilImpl.getInstance();
            final ApplicationInfo appInfo = ejbUtil.getDeployment().get((String)initialContext.lookup("java:app/AppName"));
            final List<String> tempLibNames = new LinkedList<String>();
            for 
(ModuleInfo moduleInfo : appInfo.getModuleInfos()) {
final String jarName = moduleInfo.getName();
if (jarName.endsWith(".jar")) {
    final String moduleName = jarName.substring(0, jarName.length() - 4);
    tempLibNames.add(moduleName);
....

Note jarName.endsWith(".jar") part. This check for file extension basically prevents all beans that live inside "*.war" being discovered when doing cycle in lookupSimpleForm method:

private static Object lookupSimpleForm(InitialContext ic, String name, EjbComponentProvider provider) throws NamingException {
        if (provider.libNames.isEmpty()) {
            String jndiName = "java:module/" + name;
            return ic.lookup(jndiName);
        } else {
            NamingException ne = null;
            for (String moduleName : provider.libNames) {
String jndiName = "java:app/" + moduleName + "/" + name;

because now we never see war file in provider.libNames collection. This breaks my and not only my (https://java.net/jira/browse/GLASSFISH-21114) application and should be fixed.

Environment

Glassfish 4.1 (jersey module version 2.10.4)

Affected Versions

[2.10, 2.13]

[glassfishrobot]

Reported by gray

[glassfishrobot]

@AdamLindenthal said: Hi Gray,

thanks for creating the issue. I am moving it to backlog, so that we can plan it for one of the future sprints.

Regards, Adam

[glassfishrobot]

sparksis said: Hi Adam,

Is there an ETA on when this could be revisited? As is glassfish 4.1 does not support JAX-RS with @Stateless EJBs in web archives.

Thanks,

[glassfishrobot]

lberteau said: Hi everyone,

If it may help, I have noticed that I have this issue within 32 bits environnements. The same code works fine within a 64 bits JDK.

Don't have a clue about the reasons, but that's what I observed.

Regards, Laurent

[glassfishrobot]

marvinemilbrach said: posssible workaround: replace @Stateless with: @javax.enterprise.context.RequestScoped @javax.enterprise.context.ApplicationScoped @javax.enterprise.context.ConversationScoped // NOT tested @javax.enterprise.context.SessionScoped // NOT tested

[glassfishrobot]

@AdamLindenthal said: https://github.com/jersey/jersey/pull/162

[glassfishrobot]

This issue was imported from java.net JIRA JERSEY-2690