Jakarta EE Platform Call

Date: 2023-11-21 Present:

• Arjan Tijms (OmniFish)
• Jared Anderson (IBM)
• Adam Yoho (IBM)
• Ivar Grimstad (Eclipse Foundation)
• Petr Aubrecht (Payara)
• Jan Westerkamp (iJUG)
• Brian Stansberry (Red Hat)
• Dmitry Kornilov (Oracle)
• Scott Marlow (Red Hat)
• Lukas Jungmann (Oracle)
• Kenji Kazumura (Fujitsu)

Agenda and Minutes

Housekeeping

• Arjan to run the meeting Nov 7, 14, 21, and 28

Validation Maven plug-in does not support “M” qualifier

• https://github.com/eclipse-ee4j/glassfish-spec-version-maven-plugin/issues/14#issuecomment-1815413676
• For OSGI support - it needs to be dot
• ACTION: update the plugin to allow “M”
  • Anyone can help with a PR. Arjan can merge.

Jea-69 cdi centric platform-552.

• CDI EE not approved by the specification committee
• https://www.eclipse.org/lists/jakarta.ee-spec/msg03145.html

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

– - > Add programmatic API to Jakarta Persistence API to do exactly this?

Discussion about being CDI centric flares up again

• Lack of faith in our own technology disturbing?
  • Do we need a stronger platform lead / architecture board?
• Pitching ideas
  • Profile or variant of Jakarta EE with all specs that DO support CDI
  • Specs that would rather be Java SE, remove them from platform?
    • (why are they in the platform if they don’t want to support / care for the platform?)
• Are teams actually against CDI, or is this not really the case?
  • Case in point - mailing list discussions about Persistence Team being against having any kind of CDI dependency
  • BUT… Persistence already depends on CDI
  • Lukas; we are not against CDI - but no resources for 3.2 to provide the CDI integration topic in our implementations (Hibernate and EclipseLink)
  • Lukas; we also need the standalone TCKs - they need to be part of the persistence spec project. Only then we can work on the integration issues (cleaner separation of what is required in Jakarta EE and Java SE)
  • Unclear paragraphs in spec regarding EE/SE behavior - hard to read
  • CDI is planning a major release -> might be some changes
  • Duplicating or persistence.xml -> duplicated now (both implementation does this for SE support, and the server does it as well because of historic integration reasons)
  • Helidon team -> embraces CDI on MP, but has SE as well. SE does not support CDI. Dmitry -> we like the solution where specs like persistence can work with and without CDI (for MP and SE in Helidon)
  • Dmitry -> CDI becomes the platform
    • Spec is core functionality
    • CDI performs the integration
    • TCK tests spec functionality (what spec provides)
    • TCK tests (other) tests platform
  • Jan -> Part of the history? Spring vs EE.
    • Use CDI to work with all the component specs
    • “Standalone” / Java SE modes
      • Helidon SE
      • Tomcat
      • Spring Boot
  • Arjan: What do we define as “Java SE”
    • Is anything that uses CDI “non-Java SE”?
    • Why would we define CDI as “non-Java SE” when CDI does run on Java SE.
  • MicroProfile -> Everything is based on CDI. No buts, no ifs. Only config has a low-level mode for when CDI is not yet booted.
  • Dmitry -> CDI is a platform
    • It should be the main injection framework
    • It dictates some programming model
      • Declarative
      • Injection
      • And so on
  • Arjan -> Spring Boot can use Mojarra
    • Mojarra needs CDI internally, and for backing beans
    • Configure CDI to veto everything not Faces
    • Configure Spring to veto everything Faces
  • Lukas ->
    • 5.24 - “In Jakarta EE, support for dependency injection annotations as specified in the Dependency Injection for Java specification is mediated by CDI.”
    • Current integrations seems to be covered in section 5 of the platform spec, ie components supporting injection: https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#annotations-and-injection
  • ACTION: Ivar will create a document with the options. All will help fill in pros/cons etc.
• Lack of knowledge about what CDI can do / is?
• Jakarta Persistence injection of EntityManager
  • 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

Simulate disappeared SecurityManager?

• 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)

Permissions.xml

• Should we explicitly call for removing this? (tied to Security manager)