Jakarta EE Platform Call

Date: 2023-11-14 Present:

Agenda and Minutes

Currently, you need to do this:

@Produces @PersistenceContext(unitName="UserData")
@Users EntityManager userDatabaseEntityManager;

@Inject @Users EntityManager userDatabase;

—-> Move essentially that code to a CDI extension so users don’t have to add it

See https://www.eclipse.org/lists/jpa-dev/msg00191.html
- Platform pr is https://github.com/jakartaee/platform/pull/746
See https://github.com/jakartaee/persistence/pull/460
Any updates?
- May want to get to some sort of decision soon
- Prototype for CDI injection?
NO HARD dependency on CDI in persistence (needs to be used outside EE, like Spring, Tomcat, etc)
EE chapter in persistence spec (in an EE environment and only in an EE environment, it should be X and Y)
Multiple persistence providers
- Hibernate for app 1
- EclipseLink for app 2
- TopLink for app 3
Emily argued we may want to put the requirements for this in the platform spec
Transactions has a hard dependency now on CDI
- Give it an EE chapter
Servlets becoming CDI beans
- https://www.eclipse.org/lists/servlet-dev/msg00611.html
- https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#annotations-and-injection
  - Via the platform spec, Servlets get a “fake/simulated” CDI treatment, providing:
    - @PostConstruct / @PreDestroy
    - @Inject
    - Interceptors (theoretically, practice more difficult)
  - Real CDI would additionally provide:
    - Scopes
    - Decorators
    - Ability to be vetoed
    - Programmatically enhance them in extensions with all those things
    - Automatically gets new CDI features; no need to update all the various CDI simulation code

Code level security was intended for a trusted AS to run untrusted apps
Today we run AS + single App in (docker) container or Virtual PC (Xen, vmware) \