On 10/02/2021 16:29, Romain Manni-Bucau wrote: > Le mer. 10 févr. 2021 à 17:15, Emmanuel Bourg <ebo...@apache.org> a écrit : > >> Le 2021-02-10 16:36, Rémy Maucherat a écrit : >> >>> After reading everything, I'd say it's worth adding a second integrated >>> option, and think I'm now swaying towards the runtime option. The main >>> problem would be the detection of legacy webapps. We could simply >>> mandate >>> using an explicit new attribute on the Context element (and done !) so >>> nobody pays any needless costs. >> >> The runtime option still incurs a cost for the legacy applications >> because the classes and the resources have to be filtered every time the >> application is started. Ideally the application should be converted only >> once. >> > > Tomcat has work/ folder for that purpose. The ClassFileTransformer and > WebResourceFilter can dump the outputs in work/ and load it from there when > needed at restart making it almost negligible.
What you are describing is a lazy init version of the convert at deployment. The runtime solution is starting to look a lot more complex than the deploy time solution. The WebResourceFilter may be non-trivial to implement. Filtering of static resources accessed directly is relatively simple to implement - there is code doing this for a limited subset of cases already - but handing resources in JARs, WARS and JARS nested in WARs will be more complex. Another thought has occurred to me after testing the migration tool with Jira. There are a handful of ways that applications could obtain resources that would not be caught (and could not be caught) by the WebResourceFilter. Migration at the time of deployment avoids these issues. While we don;t seem to have much consensus so far, one point we do seem to have consensus on is that the user will need to do something to identify the application as needing conversion. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
