Le jeu. 10 déc. 2020 à 17:14, Mark Thomas <ma...@apache.org> a écrit :
> 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. > Hmm, there are env the parallel deployment has pitfalls and it assumes the not converted app would work no? > > 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. > Using a transformer it can be configured in context.xml so sounds "easy" (requires to move to static constant to field instances but nothing crazy). In terms of performances it is acceptable for such apps - don't forget we often add javaagents doing potentially worse + JPA adds a transformer already visiting all classes most of the time. That said a config with some jar exclusions would be welcomed to only include a few jars. > > 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? > That's why the transformer looked handy from my window: it is configurable and easy - we must keep in mind these cases will be rare, the move to jakarta is not for tomorrow IMHO and when it will come it will be all at once per spec or not. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
