Mark,
On 12/10/20 11:14, Mark Thomas 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.
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?
Read the WEB-INF/web.xml file for the web-app version?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
