search

javaee / javaee-spec

Java EE Platform Specification
https://javaee.github.io/javaee-spec
Other
389 stars 69 forks source link

Standardize the ability to get references to objects when using CDI #44

Open glassfishrobot opened 10 years ago

glassfishrobot commented 10 years ago

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.

glassfishrobot commented 10 years ago

Reported by genomeprjct

glassfishrobot commented 9 years ago

ldemichiel said: Could you please clarify what you see as the important use cases here beyond those we currently require to be supported.

glassfishrobot commented 9 years ago

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.

glassfishrobot commented 7 years ago

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