On 29/12/2021 15:55, Michael B Allen wrote:
On Tue, Dec 28, 2021 at 10:52 AM Mark Thomas <ma...@apache.org> wrote:
<snip/>
Actually it seems the migration tool behind this feature:
https://github.com/apache/tomcat-jakartaee-migration
is a better and more general solution. If it's just re-writing package
names, can any jar converted using the tomcat-jakartaee-migration tool
be used with another app server like Jetty 11?
Yes.
<snip/>
When Tomcat 10.x reaches end of life (~2030) 9.10.x releases will stop
and 9.11.x releases will start. These will essentially track Tomcat 11.x
releases but with the Java EE API rather than the Jakarta EE API.
And so on for as long as there is community demand for the Java EE
support and there are 3 Tomcat PMC members willing to vote for the release.
That is encouraging. So just to be crystal clear, Tomcat 9 will get
security fixes as if Tomcat 10 didn't exist?
9.10.x, 9.11.x etc will continue to get security fixes. It will be no
different from any other supported Tomcat version in that regard.
Is there a page on apache.org that explains what you say or are you
speaking authoritatively?
There have been variations of this on the mailing lists, presented at
conferences and on the wiki:
https://cwiki.apache.org/confluence/display/TOMCAT/Jakarta+EE+Release+Numbering
The main variation is whether we start 9.10.x now and and keep 9.Y.x
aligned with the latest Tomcat version that supports Jakarta EE or
whether we start 9.10.x after 9.0.x is EOL and keep 9.Y.x aligned with
the oldest Tomcat version that supports Jakarta EE. Either way, Java EE
support will continue.
No need for any build process changes if you don't want to. Just use
webapps-javaee and the automatic conversion.
Well the webapps-javaee dir is good for an existing application that
you don't want to touch but maybe there should also be a
WEB-INF/lib-javaee/ directory to convert individual jars? That seems
like a more likely scenario where people want to use JakartaEE but
there are a few libs that haven't made the leap.
No need. If you deploy an app with mixed libraries, Tomcat will just
convert the ones that need converting. The hard part will be building
the app as the IDE won't do the conversion. Probably simpler to use the
tool to convert the libraries, deploy them to your local Maven repo and
build from there.
Ok so the classes don't cascade effortlessly. That doesn't mean you
couldn't create a wrapper that just operates on a member.
But that means the app can't just code to one API or the other. It has
to do the wrapping. If you are prepared to that in the app you would be
better to to code to the new API as the search and replace is lot simpler.
My point was that a container, like Tomcat, can't - without a lot of
plumbing that I'm not 100% is even possible for all use cases - support
both Java EE and Jakarta EE concurrently.
Ignoring the package change, the biggest difference in Servlet 6 and the
other Jakarta EE 10 APIs (Tomcat 10.1.x) is that a lot of the deprecated
code has been removed.
Just an aside, I must say the community process worries me a little.
Say what you want about Oracle but they have provided a stable
platform for many years. Contrarily, there have historically been
community driven efforts that have produced some, lets say,
"extraneous" results. Look into the history of X.500. Or Oasis
standards like CORBA. HttpServletRequest.login() is misplaced IMO.
When people start designing by committee at conferences, I get a
twitch in my eye.
It depends a lot on how the committee is run and who is on the
committee. There are lots of good examples as well such as the HTTP specs.
For the record, HttpServletRequest.login() was defined when Oracle were
controlling the Servlet spec.
One of the advantages of moving to Eclipse is that everyone involved in
the spec, not just the spec lead, has an equal say in what goes into the
spec. A lot of long standing issues have been resolved for Jakarta EE 10
although for Servlet there are so many such issues only some could be
tackled with the time and resources available.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
