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