|<< Back to previous view|
[GLASSFISH-17412] Annotations in plain java classes shouldn't be processed Created: 12/Oct/11 Updated: 28/Feb/13
|Fix Version/s:||future release|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Participants:||Cheng Fang, Hong Zhang, omolenkamp and Sanjeeb Sahoo|
When deploying an EJB-module, Glassfish seems to scan for injection annotations in all classes, not just the ones marked as EJB.
This can lead to problems when plain java classes (no @Stateless, @Stateful, etc) contain annotations that would be invalid for container-managed classes, because Glassfish then refuses to deploy the application. It shouldn't do this, and instead ignore these annotations on unmanaged classes.
I've attached an example project that demonstrates this problem. It contains a non-EJB class AbstractTestA that contains an unresolvable @EJB annotation on a field, which causes deployment to fail:
My actual use case is only slightly more complex: I'm using a shared library jar in several EJB-modules, that contains both EJB interfaces and abstract implementations. The abstract implementations include an @EJB reference to their own interface, to be able to start certain operations in a new transaction.
Each EJB-module implements some (often not all) of the interfaces, using the provided abstract implementation. Because only the actual implementations are marked with @Stateless (etc) and the abstract ones are not, injection annotation processing should only happen for the beans that are actually implemented. This worked properly in Glassfish 2.1.
|Comment by Cheng Fang [ 12/Oct/11 02:30 PM ]|
@EJB and other annotations on the super classes of EJB bean class are part of the dependency of this EJB, and need to be processed. This is required by Java EE and EJB spec.
If some ejb-ref only apply to certain concrete EJB bean class, then the concrete bean class is better place than the common super class. You may want to use lookup, or have a non-annotated setter method in super class, to be overridden with a setter method annotated with @EJB in subclass if needed.
|Comment by omolenkamp [ 12/Oct/11 02:39 PM ]|
"@EJB and other annotations on the super classes of EJB bean class are part of the dependency of this EJB, and need to be processed. "
Yes, but what's happening is that these annotations are also processed on classes that aren't EJB's themselves, and don't have any subclasses that are EJB's either. There's no reason to do this, and it will break the setup I described.
|Comment by Sanjeeb Sahoo [ 13/Oct/11 05:53 AM ]|
Seems like a bug to me. @EJB should only be processed for classes that are "injection capable."
|Comment by Cheng Fang [ 14/Oct/11 02:21 PM ]|
Assign to deployment. Hong, can you take a look?
|Comment by Hong Zhang [ 14/Oct/11 04:33 PM ]|
Yes today we scan all the classes for annotations as it's hard to determine which we should scan and should not ahead of the time. But it might be possible to filter the processed results to remove the unwanted processing.
|Comment by Hong Zhang [ 18/Oct/11 06:13 PM ]|
Will look at this for trunk (the changes for this will be too involving for 3.1.*).
|Comment by Hong Zhang [ 28/Feb/13 01:45 AM ]|
Scrub bugs for 4.0 HCF. Did not get a chance to look into this one, as the changes for this one will be very involving, re-target for later release.