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 V2
The Java EE CDI spec was moved from the JCP project to the Eclipse Foundation as part of the move of Java EE. Red Hat led the CDI spec since its inception at the JCP, and introduce ASL as the license model as well as open source specifications, APIs and TCKs. The evolution of the EFSP happened gradually after the transition of the CDI project to the Jakarta Contexts and Dependency Injection. Eventually the Eclipse IP policy was updated to its current form, and as part of that all EE4J specification projects were assigned a Compatible Patent License type without consulting previous JCP project leads. Red Hat favors the Implementation Patent License type, and if consulted as to which patent license type was preferred, we would have choosen the Implementation Patent License type for Jakarta Contexts and Dependency Injection.
After consulting with the EMO on what options existed for chaging the current Jakarta Contexts and Dependency Injection specification patent license type, the only option given was to archive the current specification project and start a new version of the specification with the alternative patent license type. This project proposal is identical to the existing Jakarta Contexts and Dependency Injection specification project with the only change being the choice of the patent license type.
Project Scope
The Jakarta Contexts and Dependency Injection v2 project defines and maintains the Jakarta Contexts and Dependency Injection v2 specification and related artifacts.
Specification Scope
Jakarta Contexts and Dependency Injection v2 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 v2 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.
The Eclipse Foundation already owns all trademarks associated with the project.
This is a relaunch of the existing Jakarta Contexts and Dependency Injection specification project.
Updates to the existing CDI specification to produce a new CDI-lite specification are underway. This addresses changes in the use of build time creation of applications as a popular vehicle in cloud native deployments. Breaking up the existing CDI TCK to deal with circular dependency release issues is also being targetted.
The project will continue to produce specification updates as technology changes warrent and the Jakarta EE4J major releases dictate. Currently there is a CDI-lite specification underway that is expected to release within the next year.
Red Hat, IBM
The existing CDI and CDI-TCK project repositories should be used:
https://github.com/eclipse-ee4j/cdi
https://github.com/eclipse-ee4j/cdi-tck
- Log in to post comments
- Log in to post comments