On Tue, Dec 6, 2022 at 11:50 PM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> Rémy,
>
> On 12/6/22 16:42, Rémy Maucherat wrote:
> > On Tue, Dec 6, 2022 at 6:48 PM Konstantin Kolinko
> > <knst.koli...@gmail.com> wrote:
> >>
> >> пн, 5 дек. 2022 г. в 23:32, Christopher Schultz
> >> <ch...@christopherschultz.net>:
> >>>
> >>> All,
> >>>
> >>> I've started looking at the migration path at $work for Jakarta EE and
> >>> while Tomcat 10 has some fantastic features to help with that (hot
> >>> migration is killer IMO), there are still some potential barriers I'm
> >>> seeing to "slowly" migrating $work applications from Java EE -> Jakarta
> >>> EE.
> >>>
> >>> When I say "slowly", I mean "not having to write one or more large
> >>> revision-control changes to lock-step-upgrade from e.g. Tomcat 8/9 to
> >>> Tomcat 10.1."
> >>>
> >>> One specific example is that we use Apache Velocity as our
> >>> page-generation language and AIUI, these templates will not have their
> >>> text scanned and replaced with updated strings. For example:
> >>>
> >>> #if($request.getAttribute('javax.servlet.error.request_uri'))
> >>> ...
> >>> #end
> >>>
> >>> [... skipped]
> >>>
> >>> I can think of a few ways to facilitate a dual-deployment (Tomcat 8/9 vs
> >>> 10 aka Java EE vs Jakarta EE) application, at least for the specific
> >>> example I present above:
> >>>
> >>> [... skipped]
> >>
> >> 6. I think that Migration Tool can be updated to change string
> >> constants such as the above one.
>
> Does this happen at the "source" level? For example, if I have .jsp
> files does it search-and-replace .jsp source, or only the resulting
> .class files.
Yes, you can see here the extensions that are processed as text:
https://github.com/apache/tomcat-jakartaee-migration/blob/main/src/main/java/org/apache/tomcat/jakartaee/TextConverter.java#L40
Once converted they should be processed properly. For example a JSP
source that is rewritten will use jakarta everywhere and it should be
fine. The examples webapp works (JSP, taglibs, websocket, etc) ;)
> Does this work with the on-the-fly migration, or only with the "offline"
> tool?
The deployment time conversion is equivalent to running the tool with
the default configuration, so there should be no big surprises.
It's also possible to use classloading time conversion but it's more
limited (in particular: annotations are not supported, as well as spec
API classes relocation - like if your webapp includes some javax. APIs
that should be converted). The only real benefit is that it wouldn't
break proprietary software licenses.
> I'm happy to simply add *.vm to the list of things we process. That
> would actually be a good and simple fix for both me and potentially
> others looking to upgrade.
.vm is clearly not part of the list at the moment. I think it should be added.
> > It should do that here:
> > https://github.com/apache/tomcat-jakartaee-migration/blob/main/src/main/java/org/apache/tomcat/jakartaee/TextConverter.java
> > You can see the extensions that are processed in the source.
> >
> > However, there are some limitations, like the string has to appear as
> > a whole in the file, and so on. Although not strictly compliant, it
> > could be worthwhile to consider attributes names starting with
> > "javax." as if they started with "jakarta.".
>
> This limitation isn't a problem for me: we always use "full strings" for
> those kinds of things.
Ok. I'm sure there is someone out there doing PREFIX + something though.
Rémy
>
> Thanks,
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
