JakartaEE 9: Jakarta Enterprise Beans 4.0 Support

[tkburroughs]

Description of the high level feature, including any external spec links:

Support Jakarta EE 9 : Jakarta Enterprise Beans (EJB) 4.0

Feature Overview (UFO) : https://ibm.box.com/s/pwkrthkylw25pfmutyhgtb31rr2k9at2

The following will be required to support Jakarta Enterprise Beans

• Provide the release candidate API (jakarta.ejb)
• Provide ejbLite-4.0 implementation (depends on ManagedBeans: JakartaEE: Jakarta Managed Bean Support  #11850)
• Deliver ejbLite-4.0 in beta / webProfile
• Provide ejbHome-4.0 implementation
• Provide ejbPersistentTimer-4.0 implementation
• Provide ejbRemote-2.0 implementation
• Provide ejbRemoteClient-4.0 implementation
• Provide mdb-4.0 implementation
• Provide ejb-4.0 convenience feature
• Enterprise Beans 4.0 always RMIC Compatible Jakarta EE 9: Enterprise Beans 4.0 always RMIC Compatible #16237
• Provide EJB Container API for jakarta packaging Jakarta EE 9: Provide EJB Container API #18526
• Reduce requirement of PortableRemoteObject.narrow() Jakarta EE 9: Enterprise Beans 4.0 - reduce need for PortableRemoteObject.narrow() #16238
• Jakarta EE 9 support in Yoko ORB Jakarta EE 9 support in Yoko ORB #17742
• Provide testing JakartaEE 9: Jakarta Enterprise Beans 4.0 Testing #13717
• Deliver final API
• TCK Passing

Before proceeding to any items below (active development), this feature must be prioritized on the backlog, and have either the "Design Approved" or "No Design Approved" labels. Follow the Feature and UFO Approval Process.

---

When complete & mandatory, add links to the UFO (Upcoming Feature Overview) document, FTS (Feature Test Summary), and blogs post issues(s):

• UFO: https://ibm.box.com/s/pwkrthkylw25pfmutyhgtb31rr2k9at2
• FTS: Feature Test Summary - Jakarta Enterprise Beans 4.0 #15903
• Beta Blog Post (if applicable):
• Blog Post: GA BLOG - Jakarta Enterprise Beans 4.0 (part of Jakarta EE 9.1) #19395

---

List of Steps to complete or get approvals / sign-offs for Onboarding to the Liberty release (GM date)

Instructions:

• Do the actions below and mark them complete in the checklist when they are done.
• Make sure all feature readiness approvers put the appropriate tag on the epic to indicate their approval.

Design

Before Development Starts or 8 weeks before Onboarding

• POC Design / UFO Review Scheduled (David Chang) or N/A.
• POC Design / UFO Reviewed (Feature Owner) or N/A.
• Complete any follow-ons from the POC Review.
• Design / UFO Approval (Alasdair Nottingham) or N/A.
• No Design / No UFO Approval (Arthur De Magalhaes - cloud / Alasdair Nottingham - server) or N/A.
• SVT Requirements identified. (Epic owner / Feature owner with SVT focal point) No additional SVT is required for this feature beyond what will be done by the parent feature, JakartaEE: Deliver Jakarta EE 9 #9876
• ID Requirements identified (Documenting Open Liberty). (Epic owner / Feature owner with ID focal point)
• Create a child task of this epic entitled "Feature Test Summary" via this template. Add the link in above.

Beta

If your feature, or portions of it, are going to be included in a beta
Before Onboarding the beta

• Beta Fence the functionality (kind=beta, ibm:beta, ProductInfo.getBetaEdition())

1 week before beta GA

• Create, populate, and link to the Beta blog post issue

Legal

3 weeks before Onboarding

• Identify all open source libraries that are changing or are new. Work with Legal Release Services (Cass Tucker or Release PM) to get open source cleared and approved. Or N/A. (Epic Owner). New or changed open source impacts license and Certificate of Originality. Approved for beta releases; covered by JakartaEE: Deliver Jakarta EE 9 #9876

Translation

3 weeks before Onboarding

• All new or changed PII messages are checked into the integration branch, before the last translation shipment out. (Epic Owner)

Feature Complete

2 weeks before Onboarding

• Implementation complete. (Epic owner / Feature owner)
• All function tests complete. Ready for FAT Approval. (Epic owner / Feature owner)
• Review all known issues for Stop Ship. (Epic owner / Feature owner / PM)

Focal Point Approvals

2 to 1 week before Onboarding

You MUST have the Design Approved or No Design Approved label before requesting focal point approvals.

All features (both "Design Approved" and "No Design Approved")

• FAT - (OpenLiberty/fat-approvers). SOE FATS are running successfully or N/A . Approver adds label focalApproved:fat to the Epic in Github.
• Demo - (Tom Evans or Chuck Bridgham). Demo is scheduled for an upcoming EOI. Approver adds label focalApproved:demo to the Epic in Github.
• Globalization (Sam Wong - Liberty / Simy Cheeran - tWAS). Translation is complete or N/A. TVT - complete or N/A. Approver adds label focalApproved:globalization to the Epic in Github.

"Design Approved" features

• Accessibility - (Steven Zvonek). Accessibility testing is complete or N/A. Approver adds label focalApproved:accessibility to the Epic in Github.
• ID - (Karen Deen). Documentation work is complete or N/A . Approver adds label focalApproved:id to the Epic in Github.
• Performance - (Jared Anderson). Performance testing is complete with no high severity defects or N/A . Approver adds label focalApproved:performance to the Epic in Github.
• Serviceability - (Don Bourne). Serviceability has been addressed.
• STE - (Swati Kasundra). STE chart deck is complete or N/A . Approver adds label focalApproved:ste to the Epic in Github.
• SVT - (Brian Hanczaryk - APS). SVT is complete or N/A . Approver adds label focalApproved:svt to the Epic in Github.

Ready for GA

1 week before Onboarding

• No Stop Ship issues for the feature. (Epic owner / Feature owner / Release PM)
• Ship Readiness Review and Release Notes completed (Epic owner / Feature owner / Release PM)
• Github Epic and Epic's issues are closed / complete. All PRs are committed to the master branch. (Epic owner / Feature owner / Backlog Subtribe PM)

1 week before GA

• Create, populate, and link to the Blog post issue. Covered by Covered by JakartaEE: Deliver Jakarta EE 9 #9876, with specifics detailed here : GA BLOG - Jakarta Enterprise Beans 4.0 (part of Jakarta EE 9.1) #19395

Other deliverbles

• OL Guides - (Yee-Kang Chang). Assessment for OL Guides is complete or N/A. No guides for EJB.
• WDT - (Leonard Theivendra). WDT work complete or N/A. Covered by JakartaEE: Deliver Jakarta EE 9 #9876 ; See JakartaEE: IDE Tools Story for Jakarta EE 9 #11989
• Blog - (Laura Cowen) Blog article writeup (Epic owner / Feature owner / Laura Cowen) Covered by JakartaEE: Deliver Jakarta EE 9 #9876

[jhanders34]

From the UFO socialization part 1 on Feb 26, here are the notes that I took:

Communication

• Documentation updates. openliberty.io docs to talk about what APIS are removed, what's new, etc

Done - Communication section updated with comment to provide doc updates for what has changed

Technical Background missedPersistenceTimerAction

• Add information about the values ALL vs ONCE
• Instead of saying default value, say "if the property is not set"

Done - Decision was made to not change missedPersistentTimerAction, therefore this information has been removed from the UFO. missedPersistentTimerAction will function the same as prior spec features.

Feature Design rmicCompatible

• Just don't do it at all. Don't need it any more. Just do true by default with no way to change it for 4.0.

Done - These section and later configuration section have been updated to indicate that enterpriseBeansRemote-4.0 will always be RMIC compatible. The existing JVM property will not apply to 4.0. ejbRemote-3.2 will remain unchanged.

Feature Design missedPersistenceTimerAction

• Concerns about changing the default behavior since customers depending on the old default would not know they need to configure something to enable it.

Done - - Decision was made to not change missedPersistentTimerAction, therefore this information has been removed from the UFO. missedPersistentTimerAction will function the same as prior spec features.

This was the last slide we talked about and will be where we start for the Part 2 of the UFO socialization.

[jhanders34]

Notes from part 2 of the UFO socialization from today:

Configuration

• Content for these slides go away since not making changes

Done - Slide updated to indicate that all existing EJB configuration will be supported the same as prior EJB spec level features. No configuration changes.

Developer Experience

• Remove the second bullet

Done - removed the second bullet that referenced a new "rmicCompatible" configuration attribute; the attribute will not be provided; enterprise beans 4.0 will always be compatible.

Deprecation & Stabilization

• Remove the ejbHome and ejbRemote stabilization

Done - Slide updated to indicate that the changes in the specification to make the EJB 2.x APIs optional and to remove EJB 2.x remote interoperability have NO effect on deprecation/stabilization. Both features will continue to be supported for Jakarta EE 9.

Beta

• Remove the rmicCompatible bullet

Done - rmicCompatible configuration will not be added; removed from the slide.

System test

• System test may need to update applications to not use APIs that have been removed.

Done - slide updated to indicate system test may need to be updated if using removed methods.

Migration impact

• Update to include jakarta.ejb search as well.
• Add in the SessionContext.getMessageContext() method. Doesn't look like we scan for it today.

Done - Slide updated to indicate both "javax" and "jakarta" version of methods should be included in search, and added the SessionContext.getMessageContext() method (for JAX-RPC).

[tkburroughs]

All updates requested from the UFO Design Review have been made and new UFO has been uploaded.

[skasund]

For got to add this earlier, but L2 has requested STE slides for this feature. The STE template can be found at the links below. You can use either one to create the education.

Slide Template: https://ibm.box.com/s/1an42g7zdgmaj84w7dft0indqfgi8ffm

Github Template: https://pages.github.ibm.com/WASL3/site/STE/about

Please upload the completed slides to the same 'STE Archive' BOX folder and let me know they're complete or provide me the Github link. Thanks!

[tkburroughs]

@skasund The STE slides have been uploaded to BOX : https://ibm.box.com/s/uus99y5b29y0snil4hbq3s9r2u0jlv2b
Title : STE-11450-Jakarta-Enterprise-Beans-4.ppt

[skasund]

@tkburroughs Thanks for the slides. I've approved this feature.

[tkburroughs]

Serviceability Approval Comment - Please answer the following questions for serviceability approval:

1. UFO -- does the UFO identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation?

The UFO indicates that there are no changes that effect serviceability. The new enterpriseBeans-4.0 features
provide the exact same functionality as the prior ejb-3.2 features.  There are no new problems to document. 
The enterpriseBeans-4.0 implementation is the same as the prior ejb-3.2 implementation.

2. Test and Demo -- As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team).
   a) What problem paths were tested and demonstrated?
   b) Who did you demo to?
   c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that L2 should be able to quickly address those problems without need to engage L3?

The UFO indicates that there are no changes that effect serviceability. The new enterpriseBeans-4.0 features
provide the exact same functionality as the prior ejb-3.2 features.  There are no new problems to demo.

3. SVT -- SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered.
   a) Who conducted SVT tests for this feature?
   b) Do they agree that the serviceability of the problems they encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without need to engage L3?

a) Brian Hanczaryk  & Jagadeeswar Gangaraju
b) No serviceability issues to evaluate; the same SVT applications as used for Jakarta EE 8 were transformed
for Jakarta EE 9; no differences in behavior related to EJB.

4. Which L2 / L3 queues will handle PMRs for this feature? Ensure they are present in the contact reference file and in the queue contact summary, and that the respective L2/L3 teams know they are supporting it. Ask Don Bourne if you need links or more info.

This feature has the same L2/L3 teams supporting it as the Jakarta EE 8 features.

5. Does this feature add any new metrics or emit any new JSON events? If yes, have you updated the JMX metrics reference list / Metrics reference list / JSON log events reference list in the Open Liberty docs?

The same metrics that exist for Jakarta EE 8 are relevant for Jakarta EE 9 features as well.
There are no new ones that are added.

[chirp1]

Approving this epic for the doc issue at https://github.ibm.com/websphere/liberty-docs/issues/2475 See my additional comments in the doc issue.

[tkburroughs]

All work complete; closing.