I see a lot of value to the runtime solution cause it is the only one enabling an ops only migration so for all the softwares in "run only" phase it is the only option. However the agent or transformer is the least invasive solution cause it does not require to patch core libs and will avoid app dependencies conflicts/issues (assuming asm is already there as in tomee/meecrowave or shaded with relocation).
Just my 2 cts Le mer. 25 déc. 2019 à 04:47, Adam Rauch <a...@labkey.com> a écrit : > > 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 > >
