On 12/21/2019 3:11 AM, Rémy Maucherat wrote:
On Sat, Dec 21, 2019 at 7:36 AM Adam Rauch <a...@labkey.com
<mailto:a...@labkey.com>> wrote:
I've watched with great interest the recent list discussions
surrounding
javax -> jakarta renaming and the draft release numbering plan. I'm
curious: Would the Tomcat team consider making a Tomcat release that
supports BOTH the javax and jakarta package names?
If you've read the discussions, then you can see the current plan is
to provide a deployment tool.
So as you can see in the plan, we will have a 9.x release branch for
javax.* supported "forever", and branches for jakarta.* support moving
forward (including a tool for javax.* -> jakarta.* conversion).
Now, there's no plan *right now* for a Tomcat which allows
Frankenstein webapps. Personally, I think there will always be
problems, and that it's a good time at some point to kill off the long
deprecated and unsupported EE libraries that are still out there. If
unintrusive classloader magic can happen easily, then why not I guess.
Other Apache projects like TomEE and Meecrowave have the exact same
"need", and most likely all will use the same code for that javax.* ->
jakarta.* support.
Rémy
Hi Rémy,
Yes, I see that 9.x javax.* will be supported for a long time and I'm
all in favor of killing off deprecated EE libraries. I want to encourage
our users to migrate to Tomcat 10.x and future releases as quickly as
possible, but I'm concerned that 9.x to 10.x will be a very difficult
transition for those who deploy webapps like the one we develop. With
the current plan, I don't see a scenario where our users can upgrade to
the next release of Tomcat, test that change, and then upgrade our
webapp. Because of the package rename, they will need to be upgraded in
lockstep, which has never been the case before. I see the value of a
short-term "transition" release that helps ease this burden by
supporting webapps using either package, but if others don't, then never
mind.
Maybe I've misunderstood the migration tool, but it looks like a great
tool for developers like me, not a tool that will directly help
non-developers who deploy pre-built Tomcat webapps.
As for Romain's question about doing the transformations in the
classloader, I started with a classloader approach (my classloader
responded to requests for "javax.servlet.*" classes with their
"jakarta.servlet.*" counterparts). I backed away because these classes
then needed to be manipulated so they'd match the javax interfaces'
expectations, but I haven't used ASM before. And this part of the
problem (my webapp requesting javax classes that no longer exist in
Tomcat) was easily solved by simply including those classes in my jar.
The more interesting problem was adapting the objects passed in the
hand-offs between jakarta-only Tomcat and javax-only webapp (e.g.,
Filter, Servlet, FilterChain); I'm not sure a classloader would help
there. But if someone can come up with a simpler classloader (or dynamic
proxy, et al)-based approach, then I'm all for it.
Adam
