On 12/21/2019 11:49 AM, Mark Thomas wrote:
On 21/12/2019 17:45, Adam Rauch wrote:
<snip/>
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.
I think the ideal migration strategy is going to vary for different
users. Personally, I think an approach that largely mirrors what the
Jakarta projects are going (i.e. just the package rename, nothing else)
and doing that for the container and the app at the same time is the way
to go in the majority of cases but I appreciate that that is just my view.
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.
The idea is that anyone can take a Java EE 8 app that runs on Tomcat 9,
run it through this migration tool and then run the migrated app on
Tomcat 10. We aren't there yet (I've only tested a JSTL API and
implementation) but my intention is to use apps like Jira to test it.
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.
This is one of the approaches considered in previous discussions. It is,
essentially, what the migration tool does. I think it is better to do
this conversion in advance rather than take the performance hit in a
running application. It is actually fairly simple to do as you only need
to modify the String constants.
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.
I spent a bit of time thinking about this but didn't get as far as
coding it. I came to the conclusion it could get very messy once you
start wrapping requests and dispatching them and decided to focus on the
migration tool instead.
Overall, I think it is good that there are a range of tools supporting a
range of approaches. As users start the migration progress, hopefully
we'll get some feedback and we can refine the tools and/or the approaches.
I'd encourage you to put your code somewhere where others can look at it
(GitHub being the obvious choice these days) and I'd ask you to consider
using the Apache License v2 as that makes it very easy to integrate into
Tomcat at some point in the future if that turns out to be the best
thing to do.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail:dev-h...@tomcat.apache.org
Mark,
Thanks very much for your response. I agree the ideal migration strategy
will vary and a build-based (or post-build) tool should work for most
developers. But if there's sufficient demand for a run-time migration
layer, I believe the implementation would be fairly straightforward and
the result reasonably efficient.
All of my proof-of-concept code is available on Github:
https://github.com/labkey-adam/jakarta-javax
Most of the code carries the Apache 2.0 license already (e.g., the
javax.servlet and javax.el classes copied from Tomcat sources), but I'll
add a top-level license file to clarify that the entire repo is Apache 2.0.
FilterChainAdapter illustrates the simple approach:
https://github.com/labkey-adam/jakarta-javax/blob/master/src/javax/servlet/FilterChainAdapter.java
Objects are wrapped, but the Adapters helper class unwraps known
wrappers to minimize object creation. If we were to move forward with
this approach, I'd want to restructure the code, moving the new classes
out of javax.servlet into their own package. And, of course, adding the
rest of javax.servlet and wiring up other adapters as needed.
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
