Skip to main content

Jakarta EE Platform Project

Home for the Jakarta EE Platform Team

Jakarta EE Monthly Platform Architecture Call

Date: 2023-06-06

Present:

  • Jan Westerkamp (iJUG)
  • Ed Burns (MSFT)
  • Jared Anderson (IBM)
  • Emily Jiang (IBM)
  • Jim Krueger (IBM)
  • Nathan Rauh (IBM)
  • Lukas Jungmann (Oracle)
  • Scott Marlow (Red Hat)
  • Arjan Tijms (OmniFish)
  • Tanja Obradovic (Eclipse Foundation)
  • Dmitry Kornilov (Oracle)
  • Petr Aubrecht (Payara)
  • Werner Keil (Committer/Ambassador)
  • Scott Stark (Red Hat)
  • Ed Bratt (Oracle)

Agenda and Minutes

Goal: ACTION: Ed to kick off discussion on new-to-EE11 specs on platform-dev. These notes are meant to capture the dimensions of discussion.

  • Blockers for inclusion now?
  • Reasons for inclusion now?
  • Which target profile?
  • Reasons they have not been included thus far?
  • This is a big deal. Not to be taken lightly.
    • Need rigor
    • Formal vote on mailing list
  • If the platform project runs a vote, and it passes, then the spec committee will likely pass it.
  • Jakarta MVC
    • Inclusion history
      • Only one impl? But the one impl is designed to be cross-runtime already (Rest Easy or Jersey).
      • Nobody is using it?
      • Nobody is requesting it?
  • Jakarta NoSQL
    • Target profile start: web?
    • Inclusion history
      • Many of the same factors as MVC.
    • Platform integration
      • Are the connections managed such that they show up in other specs? For example, if there is a transactional aspect, don’t we need to represent that in Jakarta Transactions somehow.
      • Is there any integration with Bean Validation? CDI?
    • These questions should be represented as issues in the Jakarta NoSQL repo.
    • What about the absence of a “driver” concept?
  • Jakarta Data
    • Target profile start: web?
    • Inclusion history
      • First time at the gate
      • Spring Data similarity. Layer on top of JPA.
    • Data does define a number of aspects of platform integration.
    • Jan shared some aspects of Spring Data vs. the way Jakarta Data is proceeding.
      • There was some disagreement about the extent to which the Data team did reach compromise.
  • Jakarta Config
    • Target profile start: core?
    • MicroProfile integration.
    • Plan review has not been submitted
    • Current state is very early
    • Included here for completeness \

Marlow: Feedback on EE 8 Platform TCK challenge issues/1176

  • ACTION: Arjan to seek guidance from Servlet team to inform the decision that will be made at the platform level.
  • We likely won’t have time to discuss but feedback on the issue or Platform ml is appreciated…
  • In summary, the ask is to stop packaging EJB interface classes in the WAR module in EARs but that is besides the point of the challenge.
  • We only have service releases for the past two (major EE) releases (EE 9/10) but could still approve if needed to allow EE 8 results to contain failures for approved challenges.
  • https://www.eclipse.org/lists/ejb-dev/threads.html#00278 has some discussion for the challenge but no conclusion.
  • Partial paste From 8.3.1. Web Container Class Loading Requirements
    • “Components in the web container may have access to the following classes and resources. Portable applications must not depend on having or not having access to these classes or resources. \

The content of any Jakarta Enterprise Beans jar files included in the same ear file. \

  • From EE 10 Platform spec 8.1.1. Component Creation
    • “A Jakarta EE module is a collection of one or more Jakarta EE components (web, Jakarta Enterprise Beans, application client, or Jakarta Connector) with an optional module deployment descriptor of that type. Any number of components of the same container type can be packaged together with a single Jakarta EE deployment descriptor appropriate to that container type to produce a Jakarta EE module. Components of different container types may not be mixed in a single Jakarta EE module, except for the packaging of Jakarta Enterprise Beans components within a web module. \
  • Partial paste From 8.2.1 Bundled Libraries
    • “1. A .ear file may contain a directory that contains libraries packaged in JAR files. The library-directory element of the .ear file’s deployment descriptor contains the name of this directory. If a library-directory element isn’t specified, or if the .ear file does not contain a deployment descriptor, the directory named lib is used. An empty library-directory element may be used to specify that there is no library directory. \
    • All files in this directory (but not subdirectories) with a .jar extension must be made available to all components packaged in the EAR file, including application clients. These libraries may reference other libraries, either bundled with the application or installed separately, using any of the techniques described herein. \

[Emily] Jakarta Security and MP JWT interlock call

[Emily] Removing Managed Beans spec from Arjan

  • EE 10 status
  • EE 11 status
    • https://github.com/jakartaee/jakartaee-platform/issues/700
    • Surfaced the need to do a Plan Review of the Common Annotations spec for EE 11 to accommodate this removal. Scott Stark graciously volunteered to issue this plan review PR. This would be a SemVer MAJOR release. 3.x. This is another thing that ties in to the ongoing discussion in the Specification Committee regarding backward compatibility and its use or non-use of SemVer.
    • Lukas observed this will have cascading effects on all other specs. Jared did indicate some research had been done regarding the set of places where this change would need to be made. This is another reason why the Wave discussion needs to be progressed to a completed state.

Back to the top