On Wed, Feb 17, 2021 at 10:52 AM Mark Thomas <ma...@apache.org> wrote:
> On 17/02/2021 09:49, Rémy Maucherat wrote: > > On Wed, Feb 17, 2021 at 10:23 AM Mark Thomas <ma...@apache.org> wrote: > > > >> On 16/02/2021 16:07, r...@apache.org wrote: > >>> This is an automated email from the ASF dual-hosted git repository. > >>> > >>> remm pushed a commit to branch master > >>> in repository https://gitbox.apache.org/repos/asf/tomcat.git > >>> > >>> > >>> The following commit(s) were added to refs/heads/master by this push: > >>> new abd1dea Allow casual runtime use of the migration tool > >>> abd1dea is described below > >>> > >>> commit abd1dead7804e99e3215e8e01a6cf7448a6b9f36 > >>> Author: remm <r...@apache.org> > >>> AuthorDate: Tue Feb 16 17:06:27 2021 +0100 > >>> > >>> Allow casual runtime use of the migration tool > >>> > >>> This allows specifying a profile which will be used for a > >>> ClassFileTransformer. Nothing much to report, it does basic things > >> but > >>> does not do classloader resources or static files. > >> > >> I was about to query why you are using reflection when I remembered that > >> > > > > Will remove it obviously, just testing ... > > Cool. > > >> the library isn't availaable by default. I was planning on changing that > >> as soon as 0.2.0 was released as part of my implementation of migration > >> at deployment time. > >> > >> Once the library is available by default we can simplify this some. > >> > > > > If you want it available by default "soon", then a new tag is needed as > the > > 0.2.0 shaded JAR causes an error (the classpath attribute of the manifest > > causes a failure as it tries to lookup for the dependent JARs). > > We should be able to avoid that by adding it to the list of JARs not to > scan (which we would want to do anyway as there is no need to scan it). > Oops, I had forgotten that, "problem solved" since it has to be done anyway, I agree :) The runtime hack works well enough to play but is obviously unreliable. Example: with the Tomcat 9 examples webapp, the included JSTL impl won't work since the classes there are not statically converted to jakarta. A deploy time tool is much more appropriate to resolve that kind of situation and move any EE impl portions to the new namespace. Rémy > > I agree the classpath needed fixing for other use cases. > > >> I was also planning on adding migrate.[sh|bat] scripts to the bin > >> directory so the migration tool was available on the command line. > >> > > > > Good idea ! > > Thanks. > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
