Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
Jakarta Contexts and Dependency Injection
This project is created as part of the process of transitioning Java EE 8 technologies to the Eclipse Foundation as described in The EE4J Project Top Level Project Charter. Unlike most of the Java EE specifications, Contexts and Dependency Injection was led by a non-Oracle organization, namely Red Hat.
The project aims to continue the standardization work of the Contexts and Dependency Injection (CDI) specification, which is part of the Java EE platform, but which also is designed since version 2.0 for use in Java SE environments. Previous revisions of that specification were created under the Java Community Process (JCP):
- CDI 1.0 (JSR 299), part of Java EE 6
- CDI 1.1 and 1.2 (JSR 346), part of Java EE 7
- CDI 2.0 (JSR 365), part of Java EE 8
Quoting the CDI2.0 specification, its goals are these:
This specification defines a powerful set of complementary services that help to improve the structure of application code.
A well-defined lifecycle for stateful objects bound to lifecycle contexts, where the set of contexts is extensible
A sophisticated, typesafe dependency injection mechanism, including the ability to select dependencies at either development or deployment time, without verbose configuration
Support for Java EE modularity and the Java EE component architecture - the modular structure of a Java EE application is taken into account when resolving dependencies between Java EE components
Integration with the Unified Expression Language (EL), allowing any contextual object to be used directly within a JSF or JSP page
The ability to decorate injected objects
The ability to associate interceptors to objects via typesafe interceptor bindings
An event notification model
A web conversation context in addition to the three standard web contexts defined by the Java Servlets specification
An SPI allowing portable extensions to integrate cleanly with the container
The services defined by this specification allow objects to be bound to lifecycle contexts, to be injected, to be associated with interceptors and decorators, and to interact in a loosely coupled fashion by firing and observing events. Various kinds of objects are injectable, including EJB 3 session beans, managed beans and Java EE resources. We refer to these objects in general terms as beans and to instances of beans that belong to contexts as contextual instances. Contextual instances may be injected into other objects by the dependency injection service.
To take advantage of these facilities, the developer provides additional bean-level metadata in the form of Java annotations and application-level metadata in the form of an XML descriptor.
The use of these services significantly simplifies the task of creating Java EE applications by integrating the Java EE web tier with Java EE enterprise services. In particular, EJB components may be used as JSF managed beans, thus integrating the programming models of EJB and JSF.
It’s even possible to integrate with third-party frameworks. A portable extension may provide objects to be injected or obtain contextual instances using the dependency injection service. The framework may even raise and observe events using the event notification service.
An application that takes advantage of these services may be designed to execute in either the Java EE environment or the Java SE environment. If the application uses Java EE services such as transaction management and persistence in the Java SE environment, the services are usually restricted to, at most, the subset defined for embedded usage by the EJB specification.
Project Scope
The Jakarta Contexts and Dependency Injection project defines and maintains the Jakarta Contexts and Dependency Injection specification and related artifacts.
Specification Scope
Jakarta Contexts and Dependency Injection defines a programming model based on component’s lifecycle and typesafe dependency injection providing multiple services and integrating with other specifications.
It also provides an eventing system and interception mechanism that adds loose decoupling to the programming model, a powerful SPI and extension mechanism allows extension of the programming model and better integration of third party frameworks.
Jakarta Contexts and Dependency Injection defines a powerful set of complementary services that help to improve the structure of application code.
-
A well-defined lifecycle for stateful objects bound to lifecycle contexts, where the set of contexts is extensible
-
A sophisticated, typesafe dependency injection mechanism, including the ability to select dependencies at either development or deployment time, without verbose configuration
-
Support for Jakarta EE modularity and the Jakarta EE component architecture - the modular structure of a Jakarta EE application is taken into account when resolving dependencies between Jakarta EE components
-
Integration with the Unified Expression Language (EL), allowing any contextual object to be used directly within a Jakarta Server Faces or Jakarta Server Pages page
-
The ability to decorate injected objects
-
The ability to associate interceptors to objects via typesafe interceptor bindings
-
An event notification model
-
A web conversation context in addition to the three standard web contexts defined by the Jakarta Servlets specification
-
An SPI allowing portable extensions to integrate cleanly with the container
For instance the following class defines a CDI bean and inject user credentials and Jakarta Persistence entity manager. It produces another bean of type User with qualifier @LoggedIn
@SessionScoped @Model
public class Login implements Serializable {
@Inject Credentials credentials;
@Inject @Users EntityManager userDatabase;
private CriteriaQuery<User> query;
private Parameter<String> usernameParam;
private Parameter<String> passwordParam;
private User user;
@Inject
void initQuery(@Users EntityManagerFactory emf) {
CriteriaBuilder cb = emf.getCriteriaBuilder();
usernameParam = cb.parameter(String.class);
passwordParam = cb.parameter(String.class);
query = cb.createQuery(User.class);
Root<User> u = query.from(User.class);
query.select(u);
query.where( cb.equal(u.get(User_.username), usernameParam),
cb.equal(u.get(User_.password), passwordParam) );
}
public void login() {
List<User> results = userDatabase.createQuery(query)
.setParameter(usernameParam, credentials.getUsername())
.setParameter(passwordParam, credentials.getPassword())
.getResultList();
if ( !results.isEmpty() ) {
user = results.get(0);
}
}
public void logout() {
user = null;
}
public boolean isLoggedIn() {
return user!=null;
}
@Produces @LoggedIn User getCurrentUser() {
if (user==null) {
throw new NotLoggedInException();
}
else {
return user;
}
}
}
CDI provides far more features. More example can be found in the existing specification document.
CDI 2.0 (as defined by JSR 365) is part of the Java EE 8 platform; as the latter is in the process of being migrated to the Eclipse Foundation and will be continued under the Jakarta EE brand, it makes sense to host CDI there too, ensuring a coherent evolution of all the Jakarta EE specifications under one umbrella.
None known
CDI will evolve from users feedback. The following leads have been discussed since 2.0 development:
- Create a light version of the spec
- Evolve to a more reactive approach
- Add more helpers to design portable extensions or extend the programming model
As all JSR-driven specifications, CDI is made up of a spec document, an API and a TCK. Their current source code (i.e. the initial contribution) can be found under the cdi-spec GitHub organization:
- cdi repo: contains specification document and the Java API source for the sepecification
- cdi-tck repo: the TCK ("Technology Compatibility Kit"), a comprehensive set of tests asserting complience of CDI implementations
Red Hat has the IP rights necessary for contributing these immediately. The spec text, API code and TCK code have been developed by the members of the Bean Validation expert groups.
CDI API has the following dependecy:
- TestNG 6.8 (Apache 2.0)
It also depends on the following Jakarta EE specifications:
- Interceptors 1.2
- Expression Language 3.0
and the following Java EE specification:
CDI TCK share the same dependecies and has also the following dependencies:
- Arquillian 1.1.11 (Apache 2.0)
- ShrinkWrap Descriptors Generated Java EE Impl (Apache 2.0)
- JBoss Test Audit Utils API 1.1.4 (Apache 2.0)
- Apache commons-httpclient 3.1 (Apache 2.0)
- Htmlunit 2.9 (Apache 2.0)
and also depends on the following Jakarta EE specifications:
- Jakarta Servlet
- Jakarta Server Pages
- Jakarta Transactions
- Jakarta Enterprise Beans 3.2
- Jakarta Interceptors 1.w2
- Jakarta Annotations 1.3
- Jakarta Connectors 1.6
- Jakarta Messaging 1.1
- Jakarta Server Faces
- Jakarta Persistence
- Jakarta Web Services Metadata
- Jarkarta RESTful Web Services
- Log in to post comments
- Log in to post comments
Initial Committers
Submitted by Kevin Sutter on Thu, 07/04/2019 - 10:03
Shouldn't all of the former CDI Expert Group members be listed (or at least asked) as initial committers? CDI is a very active Java EE Specification. There should be more Initial Committers from various organizations (IBM, Apache, independents, etc). Thanks.
Re: Initial Committers
Submitted by Antoine Sabot-Durand on Mon, 07/15/2019 - 03:31
In reply to Initial Committers by Kevin Sutter
It was done on june 28th in the CDI Mailing list: http://cdi-development-mailing-list.1064426.n5.nabble.com/Moving-the-spec-to-Eclipse-Jakarta-EE-td5715219.html
I had no answer on this.
Re: Initial Committers
Submitted by Antoine Sabot-Durand on Tue, 07/16/2019 - 06:11
In reply to Initial Committers by Kevin Sutter
Message was sent on june 28th to the CDI EG ML (http://cdi-development-mailing-list.1064426.n5.nabble.com/Moving-the-spec-to-Eclipse-Jakarta-EE-td5715219.html). No one answered.
I resend personal message yesterday to the more active committer of the spec. No answer yet...
Re: Initial Committers
Submitted by Antoine Sabot-Durand on Tue, 07/16/2019 - 06:14
In reply to Initial Committers by Kevin Sutter
Message was sent on june 28th to the CDI EG ML (http://cdi-development-mailing-list.1064426.n5.nabble.com/Moving-the-spec-to-Eclipse-Jakarta-EE-td5715219.html). No one answered.
I resend personal message yesterday to the more active committer of the spec. No answer yet...
Re: initial Commiters
Submitted by Antoine Sabot-Durand on Tue, 07/16/2019 - 06:17
Message was sent on june 28th to the CDI EG ML (http://cdi-development-mailing-list.1064426.n5.nabble.com/Moving-the-spec-to-Eclipse-Jakarta-EE-td5715219.html). No one answered.
I resent personal message yesterday to the more active committer of the spec. No answer yet...