New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
glassfishrobot opened this Issue Sep 4, 2014 · 4 comments

Comments

Projects
None yet
2 participants
@glassfishrobot

glassfishrobot commented Sep 4, 2014

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

This comment has been minimized.

Show comment
Hide comment
@glassfishrobot

glassfishrobot Sep 4, 2014

Reported by genomeprjct

glassfishrobot commented Sep 4, 2014

Reported by genomeprjct

@glassfishrobot

This comment has been minimized.

Show comment
Hide comment
@glassfishrobot

glassfishrobot Nov 3, 2014

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 Nov 3, 2014

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

@glassfishrobot

This comment has been minimized.

Show comment
Hide comment
@glassfishrobot

glassfishrobot Nov 5, 2014

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 Nov 5, 2014

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

This comment has been minimized.

Show comment
Hide comment
@glassfishrobot

glassfishrobot Apr 25, 2017

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

glassfishrobot commented Apr 25, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment