Hi Romain,
On Wed, Feb 10, 2021 at 10:39 AM Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:
> Le mer. 10 févr. 2021 à 09:32, Martin Grigorov <mgrigo...@apache.org> a
> écrit :
>
> > Hi,
> >
> > On Tue, Feb 9, 2021 at 11:12 PM Mark Thomas <ma...@apache.org> wrote:
> >
> > > Hi all,
> > >
> > > I've been looking at the options to integrate the Java EE to Jakarta EE
> > > migration functionality into Tomcat 10.
> > >
> > > There are essentially two ways to do this: deployment time and runtime.
> > >
> > > The simplest solution to implement is probably a separate
> webapps-legacy
> > > directory (or some other name) where WARs and DIRs added to that
> > > directory get converted to Jakarta EE with the new version being placed
> > > in the webapps directory. There are complexities (such as handling an
> > > updates of the legacy WAR) but they should be manageable.
> > >
> > > A more complex version of the deploy time solution has the legacy web
> > > application placed in webapps, identified as a legacy webapp and then
> > > replaced with the new version (several ways to do this). The hard part
> > > here is the identification of the webapp as a Java EE app. The only
> > > reliable way to do this is class scanning and that is slow.
> > >
> > > The runtime approach converts classes and static resources as they are
> > > loaded. The classes are relatively easy to handle. A
> > > ClassFileTransformer can be added to the WebappClassLoader to do this.
> > > The static files are more of a problem. The good news is that the
> > > WebResources refactoring means static file access all goes through the
> > > same code but the filtering required essentially means we'd need to
> load
> > > static files into memory - regardless of size, convert them, and then
> > > update the cache with the converted version. That is likely to have a
> > > performance impact.
> > >
> > > Because of the performance impacts of handling static resources, the
> > > runtime approach also needs a way to identify applications that need
> > > conversion. I don't see a reliable, performant way to do that. Which, I
> > > think, leaves us with the simple deployment time approach and something
> > > (filename, special directory, something else) to mark an app as needing
> > > conversion.
> > >
> > > A final point, which probably should have been first, is is there a
> > > demand for this feature? Early indications from the users list and
> $work
> > > is that there is (going to be) a demand for this feature.
> > >
> > > Thoughts?
> > >
> >
> > We should also think about Tomcat Embedded! Many of the modern web
> > frameworks use embedded Tomcat/Jetty/Undertow.
> > I guess it should be even easier for them to set a property saying "I
> need
> > this app to be migrated" or to put it in the special folder
> > (webapps-legacy/).
> > We just need to make sure tomcat-embed is taken into account for the
> > eventual solution!
> >
>
> I'm actually not sure:
>
> 1. embed case almost never have a webapps/ folder and always uses flat
> classpath so only option is a javaagent but 2.
>
"almost never" does not mean that it is not possible to do
org.apache.catalina.startup.Tomcat#addContext("someName",
"/path/to/folder/with/static/files/which/need/to/be/migrated")
javaagent alone won't help you for any non-class files
> 2. embed case does not have this standalone status where you put an app in
> another one so if you want to change you change it in your build
>
I don't really understand you here
>
> I can see you speaking of spring-boot or so but this is all solved by maven
> shade plugin or gradle equivalent task so I wouldn't invest in a solution
> which - for this case - wouldnt be used compared to the standalone case
> which still has ops vs dev coverage and need IMHO.
>
Believe me it is not that simple.
Spring Boot Maven/Gradle plugins produce a jar file that contains other jar
files inside. Those jar files are not compressed for optimization reasons
and the Jakarta EE migration tool cannot handle that because
java.util.jar.* APIs does not provide a way to not compress, after
re-writing the classes/files.
So, a Spring Boot application cannot be really migrated to Jakarta EE.
>
>
> >
> > Martin
> >
> >
> > > Mark
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> > > For additional commands, e-mail: dev-h...@tomcat.apache.org
> > >
> > >
> >
>
