Hi,
I think its time to discuss updating our http jetty implementation which
is currently based on Jetty 9 supporting Servlet API 3.x.
As you know, the java ee specifications have moved to the Eclipse
Jakarta Project. The latest Servlet API 5 - while it is feature
compatible with version 4 - uses different packages - everything moved
from javax.foo to jakarta.foo.
And with that breaking change, code written for servlet api 4 (or lower)
does not run ootb on a servlet api 5 enabled container.
There are different solutions out there to address this, so nothing we
need to worry here about.
But with that two new major Jetty versions appeard, Jetty 10 supporting
Servlet API 4 and Jetty 11 supporting Servlet API 5 (but not 4).
When it comes to OSGi specifications, we have the http service and http
whiteboard specification, both implemented by our implementation. But
both specs only target the javax based servlet specifications.
Now, work has started in the Eclipse OSGi working group on how to
support servlet API 5 by an OSGi specification and this work will
hopefully finish throughout this year. If you want to participate,
please join the Eclipse OSGi working group.
While Jetty (and also Tomcat I believe) choose to have separate
implementations for javax servlet api and jakarta servlet api, leaving
it up to the users to either stay on old api or migrate all code, that's
not something we should do.
I think we should have an implementation that supports all existing
javax.servlet specifications as well as all upcoming jakarta servlet
based ones. That avoids migrating all code and also avoids that projects
need to maintain two versions of their code base.
Now, long story short with that I think we should base our next Http
Jetty version on Jetty 11 (servlet api 5) and make it possible to use
the http service and http whiteboard (servlet api 3/4) within that
implementation.
And once there is an OSGi specification for servlet api 5, we will
implement that in addition.
To explore the feasibility of this approach, I started this approach in
our master branch by remaning the existing implementation directories to
base-4.x/bridge-4.x/jetty-4.x. In base/bridge/jetty you will find a
servlet api 5 based implementation.
Regardless whether we pick Jetty 10 or Jetty 11 or do something
completely different, it means that a new http jetty implementation will
be API incompatible when it comes to all Jetty based API. For example
there are some changes between Jetty 9 and Jetty 11 - even if not, it is
a major version change.
And that leads me to questioning whether we should change/remove
anything? Today we have two implementations a "full" and "light" one,
where the "full" jar embeds all dependencies including Jetty and exports
these packages. The "light" one does not embed and requires you to
install a number of Jetty bundles alongside. Should we remove the "full"
version which avoids this embedding of existing bundles? We also have
some API and support for webapps - do we want to keep it? Change it?
The easiest answer is of course to leave everything as is, as this is
the easiest for our users. Best case they just need to recompile if they
depend on anything Jetty speficic.
But now is a good point to take a step back and think whether we can
improve something.
Regards
Carsten
--
Carsten Ziegeler
Adobe
cziege...@apache.org
