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. 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 > >
