eclipse-ee4j / eclipse-ee4j/jersey
Resource Class lookup fails when more than one resource class has the same name
- Dominant language
- Java
- Stars
- 730
- Forks
- 382
- PR merge metrics
- No merged PRs in 30d
Description
When multiple resource classes have the same name the lookup for that resource class fails to get the right one.
The use case I have at hands is the following: We (as in the company I work for) have a Java EE application that packages multiple modules ( wars, jars and ejb) into an ear. We segment our API into multiple different .war modules. This means that we have multiple resource classes with the same name (for example, we have a CustomerResource per .war, which answers to different URIs of the API and act accordingly to where it called from, filtering and returning different data, for example). When Jersey is trying to find the right EJB resource class for a given Request it will just load the first one it finds which naturally breaks the whole thing, because it is the wrong class answering the call.
After digging into the code I found that this happens because the Jersey class **EjbComponentProvider** performs the EJB lookup by first trying to find the class using the JNDI with only the Simple Name of the Class (in this case CustomerResource). This will fail because although both have the same name, the class in .war1 has the fully qualified name different from the one on .war2 (i.e. **com.company.apisegment1.CustomerResource** vs **com.company.apisegment2.CustomerResource**).
It happens here:
```
private static Object lookup(InitialContext ic, Class c, String name, EjbComponentProvider provider)
throws NamingException {
try {
return lookupSimpleForm(ic, name, provider);
} catch (NamingException ex) {
LOGGER.log(Level.WARNING, LocalizationMessages.EJB_CLASS_SIMPLE_LOOKUP_FAILED(c.getName()), ex);
return lookupFullyQualifiedForm(ic, c, name, provider);
}
}
```
Now, **lookupSimpleForm** will use only the simple name (CustomerResource) whereas the **lookupFullyQualifiedForm** will use the fully qualified name (com.company,apisegment1.CustomerResource). Since the **provider.libnames** List it has the classes from both wars but it is looking only for the simple name, it will load the first one that finds, which results in a natural malfunction and breaking.
I could push all of our API into a single war and play along with that, but we think our logic is a valid one (spreading API through multiple modules). And also maybe Jersey should just search for the fully qualified name anyway as it would allow for this kind of flexibility.
**Versions used**:
Glassfish 5.0.1-SNAPSHOT
Jersey 2.27
JDK 1.8.0_181
Contributor guide
Assessment
This issue has not been assessed yet.