Closed jhanders34 closed 1 year ago
Note that the Jakarta Web Services Metadata Specification will also be updated for Jakarta EE 10, but it will be merged with the Jakarta XML Web Services Specification. Just wanted the team to be aware of this merging to account for the potential additional work.
Notes from Part 1 of the UFO socialization of this feature:
Title page
Technical Background
As-is / To-be
CXF 5.0
Feature Design - Global Handler
Feature Design - wsSecurity-1.1
Enabled by default
should be changed to be Enabled by default when using xmlWS-4.0
State of SAX/StAX
Feature Design
Communciation
Java APIs/SPI xmlWS-4.0
Notes from Part 2 of the UFO socialization of this feature:
Java APIs/SPIs - xmlWS-4.0
Beta
read
should be ready
Automated Testing
Performance
Migration Impact
Feature Design - Global Handler
@jhanders34 @neuwerk If FATs are complete, pls add target:ga label. Thanks!
EOI Demo is set for the 17th January 2023
@neuwerk is globalization required? @samwatibm @donbourne @steven1046 can we get globlization, serviceability, and accessibility approvals? Thanks
See email I forwarded. Need confirmation from development of what English has changed since 23.0.0.1.
Documentation issue for this epic: https://github.com/OpenLiberty/docs/issues/5854 Information to document received. Documentation being written. Approving this epic.
Serviceability Approval Comment - Please answer the following questions for serviceability approval:
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? Yes, the xmlws-4.0 is nearly the same feature as the xmlWS-3.0, and uses the jakartaized version of jaxws-2.2, so most functionality is well tested. Two of the biggest changes to the specification and to the feature itself are the jakarta.xml.ws.Provider
implementation look, and the removal of the Global Handler as a default SPI. The Global Handler change requires users to change their own user features to account for this change. Enabling Global Handlers through a user feature is well documented, but the error that occurs if you try to run the old version of the User Feature with xmlWS-4.0 will need to be covered in the documentation, in order to help users resolve the error if they see it.
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? The jakarta.xml.ws.Provider
property change to look up an alternative implementation that the one Liberty ships. The Global Handler change from being a default API we enable with xmlWS-4.0
b) Who did you demo to? Adam Anderson
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? Yes
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? Brian Hanczaryk 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? Yes
Which L2 / L3 queues will handle PMRs for this feature? Yes 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.
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? No
L2 is good with the STE slides - STE approving
@neuwerk Please answer the Serviceability questions in https://github.com/OpenLiberty/open-liberty/issues/18746#issuecomment-1444450783 for the serviceability approval.
@pgunapal I've updated Don's comment above with my answers. Thank you!
Keeping this issue open as there is some outstanding/ongoing working involving STAX streaming support in WS-Security as described in the UFO.
@neuwerk any update on the outstanding work? Thanks
I was able to commit the last changes that were missing to close this feature out last week #25996 and #26064. With these added, the epic is closable.
Description of the high level feature, including any external spec links:
Implement the Jakarta XML Web Services 4.0 and SOAP with Attachements 3.0 specifications
When complete & mandatory, add links to the UFO (Upcoming Feature Overview) document, FTS (Feature Test Summary), and blogs post issues(s):
UFO: xmlWS-4.0
FTS: #24316
Beta Blog Post (if applicable): Beta Blog
Blog Post: https://github.com/OpenLiberty/open-liberty/issues/24615
List of Steps to complete or get approvals / sign-offs for Onboarding to the Liberty release (GM date)
Instructions:
Design
Before Development Starts or 8 weeks before Onboarding
Before proceeding to any items below (active development), this feature MUST be prioritized on the backlog, and have been socialized (e.g., UFO Review). Follow the Feature and UFO Approval Process.
Development
When active development has begun
Beta
If your feature, or portions of it, are going to be included in a beta
Before Onboarding the beta
kind=beta
,ibm:beta
,ProductInfo.getBetaEdition()
)1 week before beta GA
Legal
3 weeks before Onboarding
Translation
3 weeks before Onboarding
Feature Complete
2 weeks before Onboarding
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")
"Design Approved" features
Ready for GA
1 week before Onboarding
1 week before GA
Other deliverbles