Status message

A Jakarta Contexts and Dependency Injection V2 Creation Review has been created for this proposal.

Jakarta Contexts and Dependency Injection V2

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process) and is written to declare its intent and scope. We solicit additional participation and input from the community. Please login and add your feedback in the comments section.
Is this a specification project?
Patent License
Implementation Patent License
Parent Project
Working Group
Proposal State
Withdrawn
Background

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.

 

Scope

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.

Description

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.

Why Here?

This is a relaunch of the existing Jakarta Contexts and Dependency Injection specification project.

Project Scheduling

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.

Future Work

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.

Initial Contribution

The existing CDI and CDI-TCK project repositories should be used:

https://github.com/eclipse-ee4j/cdi

https://github.com/eclipse-ee4j/cdi-tck

 

Source Repository Type