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.
Does this work with the on-the-fly migration, or only with the "offline"
tool?
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.
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.
Thanks,
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
