Le ven. 11 déc. 2020 à 10:59, Rémy Maucherat <r...@apache.org> a écrit :
> On Thu, Dec 10, 2020 at 5:14 PM Mark Thomas <ma...@apache.org> wrote: > > > On 10/12/2020 14:52, Romain Manni-Bucau wrote: > > > Le jeu. 10 déc. 2020 à 15:49, Rémy Maucherat <r...@apache.org> a > écrit : > > >> On Thu, Dec 10, 2020 at 3:13 PM Mark Thomas <ma...@apache.org> wrote: > > >>> On 10/12/2020 13:58, Christopher Schultz wrote: > > > > <snip/> > > > > >>>> Since this is a developer tool and not a runtime library or anything > > >>>> like that, maybe we can just say "YMMV, this is available any time > you > > >>>> want it"? > > >>> > > >>> It could be a runtime library. One possibility is that we integrate > it > > >>> into Tomcat 10 somehow so that if you try and deploy a Java EE 8 WAR > it > > >>> gets automatically converted to a Jakarta EE 9 WAR. > > >>> > > >> > > >> It sounds doable with a special folder of the host (like a > > legacyAppBase), > > >> and it creates the result in the host's appBase. Like > > HostConfig.deployApps > > >> simply does this first, then moves down the usual deployments. I'm not > > sure > > >> that this is really useful though. > > >> > > > > > > Does it sound stupid to make the library a ClassFileTransformer added > on > > > the webapp classloader? Sounds the most hurtless for users even if it > > will > > > adds a small overhead (and avoids a lot of file duplication which can > be > > > harder to maintain at some point). > > > > It doesn't sound stupid at all. It was one of the options considered > > when we first started thinking about this. That was before we had the > > current implementation. With the experience of what the current > > implementation looks like we might want to revisit that discussion. > > > > My own thinking was to convert appBase/javaee.war to > > appBase/javaee##converted.war and let the parallel deployment code take > > care of deploying just the updated version. > > > > I would think a separate appBase is preferable since it's easier, and > there's nothing to detect. Everything gets processed by the conversion tool > and that's it. > > > > > > Doing conversion on the fly or at deployment/start-up time raises > > various issues that boil down to "How do we detect if conversion is > > required?" and "What are the performance impacts of doing so?". There > > are users who want to squeeze every last drop of performance out of the > > system so I think that leads to some sort of configuration option. > > > > Still not convinced by the classloading magic (the tool does a bit more > than this) and AOT would be a problem. > Same applies for the different app base, basically AOT can only work if done at build time so having a cllassfiletransfomer wired either in the config of the classloader (once again, when tuned to ignored most of commons etc by jar name and packages it will not slow down the app significantly enough to not be worth it as proven by other transformers out there - take tomee as an example ;)) and another wiring in a main - as of today - where it enables to get a new binary, potentially integrated with tomcat embedded/standalone (new Tomcat()) and then go through graalvm. > > Rémy > > > > > > Just thinking about that I thought of: > > - watch what classes are requested > > - as soon as javax.servlet.* (or one of the others is detected) stop the > > context, enable conversion and restart the context > > > > Then I thought that apps might try to determine if they are running on > > Java EE or Jakarta EE by trying to load classes. That could incorrectly > > trigger the conversion. > > > > Hmm. Anything apart from an explicitly user set flag starts to look > > potentially tricky for some use cases. > > > > Thoughts? > > > > Mark > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > >
