[
https://issues.apache.org/jira/browse/FELIX-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17730141#comment-17730141
]
Michael H. Siemaszko edited comment on FELIX-6612 at 6/7/23 2:33 PM:
---------------------------------------------------------------------
Hi Carsten,
Aim of this upgrade is to lift those to Jakarta Servlet API 6.x. Obviously, if
a module works with Jakarta Servlet 5.x and is not using any deprecated
methods, then changing dependency to Jakarta Servlet 6.x would not require any
code refactoring. Still, however, its pom.xml needs to be modified, that is why
refactoring is separate from simply changing dependency - for some, it's as
simple as that, for a lot however, refactoring is definitely needed (please see
questions mentioned in description, which relate to that).
To give you an example, just changing to Jakarta Servlet API 6.x in
`org.apache.felix.http.base` and `org.apache.felix.http.sslfilter` caused over
90+ compilation errors - due to use of deprecated methods. Why I had to go step
by step (i.e. javax 2/3 -> javax 4 -> jakarta 5 -> jakarta 6) is also mentioned
in the description / graph attached).
was (Author: JIRAUSER300649):
Hi Carsten,
Aim of this upgrade is to lift those to Jakarta Servlet API 6.x. Obviously, if
a module works with Jakarta Servlet 5.x and is not using any deprecated
methods, then changing dependency to Jakarta Servlet 6.x would not require any
code refactoring. Still, however, it's pom.xml needs to be modified, that is
why refactoring is separate from simply changing dependency - for some, it's as
simple as that, for a lot however, refactoring is definitely needed (please see
questions mentioned in description, which relate to that).
To give you an example, just changing to Jakarta Servlet API 6.x in
`org.apache.felix.http.base` and `org.apache.felix.http.sslfilter` caused over
90+ compilation errors - due to use of deprecated methods. Why I had to go step
by step (i.e. javax 2/3 -> javax 4 -> jakarta 5 -> jakarta 6) is also mentioned
in the description / graph attached).
> Upgrade Apache Felix to Jakarta Servlet API 6.x
> -----------------------------------------------
>
> Key: FELIX-6612
> URL: https://issues.apache.org/jira/browse/FELIX-6612
> Project: Felix
> Issue Type: New Feature
> Components: Health Checks, HTTP Service, Inventory, iPOJO, JAAS,
> System Ready, Web Console
> Reporter: Michael H. Siemaszko
> Priority: Major
> Attachments: Upgrade Apache Felix to Jakarta Servlet API 6.x.pdf
>
>
> Goal is to upgrade all relevant Apache Felix modules, which currently are
> using either +Jakarta Servlet API 5.x+ or J{+}ava Servlet{+}, to {+}Jakarta
> Servlet API 6.x{+}.
> Attached Mikado graph ({color:#000080}+[https://mikadomethod.info/]+{color})
> has all so far identified prerequisites listed, as well as progress on path
> to main goal – i.e. items already completed are checked off
> ({*}{color:#57d9a3}green icon{color}{*}). Code is shared via
> [https://github.com/ideas-into-software/felix-dev/tree/jakarta-servlet-6-x]
> (no pull request for now – please see sections ‘Questions’ and ‘Next steps’
> below).
> Before starting, I asked on Apache Felix Users list
> ({color:#000080}+[https://www.mail-archive.com/users@felix.apache.org/msg18693.html]+{color}),
> as well as researched if there is any ongoing effort to upgrade Apache Felix
> to Jakarta Servlet 6.x (issues / pull requests, etc.). Besides
> {color:#000080}+https://issues.apache.org/jira/browse/FELIX-6389+{color},
> which resembles this effort, I did not find anything. However, that issue is
> open since 22/02/2021 and there has been no updates since 09/01/2022, as well
> as no code shared as part of it. If any progress was made as part of
> {color:#000080}+https://issues.apache.org/jira/browse/FELIX-6389+{color},
> kindly please provide status update and perhaps these efforts can be merged.
> h1. Modules affected
> Modules with dependency on Java Servlet or Jakarta Servlet.
> h2. org.apache.felix.http
> * org.apache.felix.http.parent
> * org.apache.felix.http.base
> * org.apache.felix.http.bridge
> * org.apache.felix.http.inventoryprinter
> * org.apache.felix.http.itest
> * org.apache.felix.http.jetty
> * org.apache.felix.http.proxy
> * org.apache.felix.http.samples.whiteboard
> * org.apache.felix.http.servlet-api
> * org.apache.felix.http.sslfilter
> * org.apache.felix.http.webconsoleplugin
> h2. org.apache.felix.webconsole
> * org.apache.felix.webconsole
> * org.apache.felix.webconsole.plugins.deppack
> * org.apache.felix.webconsole.plugins.ds
> * org.apache.felix.webconsole.plugins.event
> * org.apache.felix.webconsole.plugins.gogo
> * org.apache.felix.webconsole.plugins.memoryusage
> * org.apache.felix.webconsole.plugins.metatype
> * org.apache.felix.webconsole.plugins.obr
> * org.apache.felix.webconsole.plugins.packageadmin
> * org.apache.felix.webconsole.plugins.scriptconsole
> * org.apache.felix.webconsole.plugins.shell
> * org.apache.felix.webconsole.plugins.subsystems
> * org.apache.felix.webconsole.plugins.upnp
> * org.apache.felix.webconsole.plugins.useradmin
> h2. org.apache.felix.healthcheck
> * org.apache.felix.healthcheck.core
> * org.apache.felix.healthcheck.webconsoleplugin
> h2. Other
> * org.apache.felix.jaas
> * org.apache.felix.example.jaas.app
> * org.apache.felix.example.jaas.jdbc-h2
> * org.apache.felix.ipojo.webconsole
> * org.apache.felix.systemready
> * org.apache.felix.servicediagnostics.plugin
> * org.apache.felix.inventory
> h1. Questions
> # Regarding modules affected, are there any additional modules which should
> be taken into account?
> # Regarding modules affected, should any of the modules listed be dropped
> from that list ? (e.g. some may be out of date / replaced by other already)
> # Do you know of any ongoing effort to migrate `org.osgi.service.http`
> specification to Jakarta ? How otherwise should modules currently using
> `org.osgi.service.http` specification API classes and methods be refactored ?
> I am aware of
> {color:#000080}+[https://github.com/eclipse-equinox/equinox/issues/183]+{color}
> but it is not clear to me from that discussion if any such effort will be
> actually made.
> # Do you know of any ongoing effort to upgrade `org.osgi.service.servlet` to
> support Jakarta Servlet API 6.x ?
> # If `javax.servlet` dependency is removed from
> `org.apache.felix.http.base`, wouldn't the wrappers become obsolete ? I.e.
> shouldn't `org.apache.felix.http.base.internal.jakartawrappers` and
> `org.apache.felix.http.base.internal.javaxwrappers` be dropped then and
> Jakarta Servlet API used directly ?
> # Should Jakarta Servlet API 5.x be supported in parallel with Jakarta
> Servlet API 6.x (as hinted at in
> {color:#000080}+[https://www.mail-archive.com/users@felix.apache.org/msg18694.html]+{color}),
> or only Jakarta Servlet API 6.x ?
> # Should `org.apache.felix.http.servlet-api` module be kept once dependency
> on Java Servlet API is removed from it?
> # Should this be merged to `master` branch @
> {color:#000080}+[https://github.com/apache/felix-dev]+{color} once ready, or
> dedicated branch should be used (e.g. `jakarta-servlet-6-x`)
> h1. Next steps
> # Please provide answers to questions mentioned in previous section.
> # If you see any of the prerequisites missing from Mikado graph, please
> mention those.
> # Please create a dedicated branch @
> {color:#000080}+[https://github.com/apache/felix-dev]+{color} (e.g.
> `jakarta-servlet-6-x`) unless this should be merged to `master` once ready.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
