eclipse-ee4j / eclipse-ee4j/jersey
GF: Fail to lookup EJB that is declared in war module of an EAR
- Dominant language
- Java
- Stars
- 730
- Forks
- 382
- PR merge metrics
- No merged PRs in 30d
Description
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](https://java.net/jira/browse/JERSEY-2122) 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 tempLibNames = new LinkedList();
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](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]
Contributor guide
Assessment
This issue has not been assessed yet.