Upgrade to Tomcat 10 - Githubissues

boubaker commented 1 year ago

Rationale

The used Servlet container Apache Tomcat had evolved to introduce a newer version 10.1 that is part of Jakarta EE 9. This change implies multiple breaking changes and should be operated to benefit from newer third party libraries upgrades.

1. Technical Requirements

Upgradability

This change has to upgrade any third party library that isn't compliant with Servlet Container 6.0. When third party libraries aren't compliant with Jakarta EE, we will have to enumerate them to decide whether to fork or to drop it.

4. Software Architecture

Impacted components

Portlet Container (PC): the provided JSR 168 and JSR 286 API Jars aren't compliant with Jakarta EE package names. Same thing for the JSR 362 which is not implemented in our PC. For Portlet Container bridge, we will have to delete bridges knowing that it's not compliant with Servlet Container of Jakarta EE anymore and just keep the Portlet Container engine as an internal engine to display portlets in a single web page. (Delete compatibility with Portlet Container specifications knowing that it's not compatible with Jakarta EE anymore)
Kernel Containers IoC: the portal container uses the Servlet Context to unify the services definition through addons. This implementation has to evolve to be compliant with Jakarta EE packages.
Web Container Integration (WCI): this tiny Jar is used to integrate the Kernel mechanisms into Web Cotnainers and has to be moved into kernel to reduce the number of projects to release and reduce maintenance cost of projects at the same time as it has to be upgraded to Jakarte EE 10 packages.
WS: we had implement the JSR 311 (JAX-RS) in the project ws. This implementation hasn't evolved to JSR 370 and isn't maintained to be useful as framework for community. Thus, we will aim to upgrade our REST APIs to rely on Spring Rest APIs in future releases (see MIP#57 ). This API migration will take some time to be done smoothly without breaking the existing implementation using the old implementation. In order, to keep this compatibility, the project WS has to continue being compatible with Jakarta EE and thus being migrated by dropping useless features not used in current RESTful APIs in higher levels.
SSO: we had deprecated some SSO long time ago for spnego, cas and keep a compatibility for SAML v2 only. By upgrading to Jakarta EE, we will have to rework the SAML v2 integration to replace picketlink with a more modern and maintained third party library for SAML integration, which should be treated in a different MIP. In this MIP, we will have to fork picketlink-federations to update with Jakarta EE package names.

Impacted third party libraries

commons-fileupload:commons-fileupload: has to be replaced by org.apache.commons:commons-fileupload2-jakarta in UploadService only. Knowing that this library is used only for processing uploaded files through HTTP Requests. Knowing we have a dev best practice to exclusively use /portal/upload endpoint for Binary files uploading, we has to delete (instead of upgrading it) the possibility to upload files through REST endpoints.
org.apache.portals.bridges:portals-bridges-common: a dependency that allows to add portlets using third party libraries in JSR 286 compliant Portlet Cotnainer. This dependency has to be dropped as explained above since we don't aim to keep a non-standard JSR implementation inside Jakarta EE compliant Servlet Container.
org.juzu:*: a deprecated dependency that should be completely removed instead of upgrading it to be compliant with Servlet Container 6.0.

boubaker commented 1 year ago

PRs - Part 1:

boubaker commented 1 year ago

Ready to tech review @rdenarie