Description

glassfishrobot

opened on Sep 4, 2014

Issue body actions

Currently, if you look across the various specs, there's lots of ways to get object references. As far as I've seen, JAX-RS does it the best (definition wise) by specifying that classes annotated will be properly looked up via CDI. JSF has similarly followed suit and aligned their instance creation to CDI when within a bean archive. JMS has done an excellent job as well, with managing scopes of its managed objects.

However, we have specs like Servlet and WebSockets that don't define this behaviour. For instance, a SerlvetFilter should be a managed CDI object with an appropriate scope, and allow for proper injection, assuming it has an adequate scope and is found within a bean archive.

This type of requirement needs to come from the entire platform overall, in order to give developers a consistent programming model.

Activity

1. glassfishrobot commented on Sep 4, 2014

   

   glassfishrobot

   on Sep 4, 2014

   Author

   More actions

   Reported by genomeprjct
2. glassfishrobot commented on Nov 3, 2014

   

   glassfishrobot

   on Nov 3, 2014

   Author

   More actions

   ldemichiel said:
   Could you please clarify what you see as the important use cases here beyond those we currently require to be supported.
3. glassfishrobot commented on Nov 5, 2014

   

   glassfishrobot

   on Nov 5, 2014

   Author

   More actions

   genomeprjct said:
   I don't believe any new use case is introduced, instead existing use cases should be clarified to go one way or another.

   If you look, for example, JPA states the following:

   Entity listener classes in Java EE environments support dependency injection through the Contexts and
   Dependency Injection API (CDI) [ 10 ] when CDI is enabled[43]. An entity listener class that makes use
   of CDI injection may also define lifecycle callback methods annotated with the PostConstruct and
   PreDestroy annotations. These methods will be invoked after injection has taken place and before
   the entity listener instance is destroyed respectively.
   The persistence provider is responsible for using the CDI SPI to create instances of the entity listener
   class; to perform injection upon such instances; to invoke their PostConstruct and PreDestroy
   methods, if any; and to dispose of the entity listener instances.

   In contrast, see the equivalent paragraph within the JAX-RS 2.0 spec

   In a product that supports CDI, implementations MUST support the use of CDI-style Beans as root re-source classes, providers and Application subclasses. Providers and Application subclasses MUST be singletons or use application scope.

   The JAX-RS version is simpler, however it more clearly (at least to me) explains how the JAX-RS implementation is meant to work with the CDI container. The JPA spec on the other hand makes this very confusing. It reads as though the JPA provider must still instantiate the the EntityListener, and somehow integrate with the CDI container to populate injection points within the EntityListener. The JPA spec could instead defer to the container, similar to what JAX-RS says about using CDI-style beans as EntityListeners.

   If this were the case, then we could more generically say that across the board, if any spec wants to integrate with CDI then this is how it should be done.
4. glassfishrobot commented on Apr 25, 2017

   

   glassfishrobot

   on Apr 25, 2017

   Author

   More actions

   This issue was imported from java.net JIRA JAVAEE_SPEC-44
5. glassfishrobot

   added

   Type: New Feature

   Priority: Major

   on Apr 25, 2017
6. glassfishrobot

   assigned

   ldemichiel

   on Apr 25, 2017

Issue actions