There are imo 3 ways we can deal with the migration. All of them assume that all of our ASF projects migrate the affected packages from javax.* to jakarta.*.
A.) of course have all the customer code and libs migrated to jakarta.*. B.) ClassTransformer + ClassLoader. The ClassTransformer transforms all usage of affected packages from javax.* to jakarta.*. when the classes get loaded. The ClassLoader redirects any META-INF/services/javax.* java.util.ServiceLoader files and serves them as META-INF/services/jakarta.* C.) pretty much like B.) but as Apache Maven plugin at build time. It could provide the auto-migrated parts as attached artifact. Btw, I've done plenty of test migration a year ago already http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ https://github.com/struberg/tomcat/tree/jakarta https://github.com/struberg/openwebbeans/tree/jakarta LieGrue, strub > Am 25.12.2019 um 09:26 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
