search

OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.16k stars 597 forks source link

Current "fork" of CXF prevents easy upgrades #13920

Open andymc12 opened 4 years ago

andymc12 commented 4 years ago

Since as far back as I have worked on JAX-RS, we have always had somewhat of a "fork" of Apache CXF code for implementing JAX-RS 2.0, 2.1 and then all versions of the MicroProfile Rest Client. The "fork" works by pulling in a specific GA version of CXF from Maven Central (via Artifactory) and then overlaying only the files we need changed.

This overlaying was limited to ~20 files at one point - and while that is still unfortunate, it has since grown to over 100 files. Most of these overlayed files are to increase performance or for security optimizations specific to Liberty. We always offer to contribute fixes back to the CXF community, but the security fixes are not useful to the community as they are specific to Liberty and the CXF community has (politely) rejected many of the performance fixes due to the trouble of maintaining them.

The current amount of overlayed files make it extremely difficult, time-consuming and error-prone to upgrade to newer versions of CXF. In effect when a new version is pulled in to Open Liberty, we must hand merge the CXF changes to those 100+ files, attempting to keep intact the purity of the CXF changes as well as not break the Liberty-specific changes. This is a significant blocker to the MP Rest Client 2.0 feature development (epic issue #10786) and a blocker to general maintenance of JAX-RS 2.X and MP Rest Client 1.X features.

Here are some options for minimizing these blockers: 1) Stabilize the affected features (JAX-RS 2.X and MP Rest Client 1.X) and move to RESTEasy for MP Rest Client 2.0- yeah, I know this isn't going to fly, but I thought I'd mention it anyway... 2) Just make this a real fork (remove the quotes from "fork" :-) ) - that means we'd basically be maintaining the entire code base without much (if any) support from the Apache CXF community - again, I don't think this will fly... 3) Revert the performance changes (resulting in ~10% decrease in runtime performance...) - that accounts for the vast majority of change/overlayed files. 4) Revert many of the performance changes - specifically related to replacing hash map usage with arrays in MessageImpl - this change affects a large number of files. To avoid the performance loss, it might still be possible to overlay these changes using a class-modifying build tool like the Eclipse Transformer to change things like message.get(InputStream.class) to ((MessageImpl)message).getInputStream(). 5) Suck it up and hand-merge 100+ files every time we need to upgrade. I'm obviously not advocating for this, but it's possible. It probably adds 1-2PMs for every CXF upgrade - and could possibly spiral further out of control.

neuwerk commented 4 years ago

Since jaxrs-2.1 and jaxws-2.3/wsSecurity-X.X share a common CXF version, the Open-Liberty performance changes to CXF also affect the development and maintenance of the new JAX-WS and WS-Security features in the same way as jaxrs-2.1.

andymc12 commented 2 years ago

By "implementing", the JAX-RS/JAX-WS team is constantly looking for ways to reduce overlaid files in the Liberty source repo. It may take a long time to reach 0 overlays since there are some code changes that are too specific to Liberty. That said the teams will continue to reduce them over time.