Upgrading from WildFly 10...

[Brian Fasano]

We have a program that was built using WildFly 10 that we no longer have support for. 

We would like to upgrade the underlying WildFly version. 

What is the best path forward? Should we download Wildfly 24 and install it, or should we upgrade in steps? e.g. 10 to 12 to 16 to 20 to 24, or something like that? 

Thanks, 

-Brian

[serg.k...@gmail.com]

Hi Brian

Please refer to my article about as a start point : https://kostenko.org/blog/2019/10/migration-wildfly-10-to-18.html

I believe, you just need to  choose WF version you want.

Thanks,

BR, Sergii Kostenko

вівторок, 17 серпня 2021 р. о 18:05:34 UTC+3 brian...@gmail.com пише:

[Shawn Fox]

I'm in the process of upgrading from Wildfly 18 to 22.  I'm having problems skipping versions due to the fact that our project has an extension to a subsystem that needs to be deployed.  If you are not in that situation then it would be best to upgrade to a later version and regression test rather than 1 version at a time.  However I would still do it in several increments.  Going from 10 directly to 24 is a huge jump and if you encounter a problem you aren't going to know easily which change caused the problem.  

I took the approach of reading the release notes for each version to look for any potential issues in order to determine which versions to skip.  From what I can tell backwards compatibility doesn't seem to ever be a guarantee as deprecated concepts could be removed at some point.  Beyond Wildfly 22 when only Jakarta EE support is advertised it might get a bit harder without changing your app software and other dependencies.  The article posted by someone else seems perfect for you since it describes an approach for upgrading through Wildfly 18 which will get you part way to your goal.  If I were you I'd do that first. Starting with Wildfly 20 there seems to be an issue with the undertow-servlet that is causing me problems.  Starting with Wildfly 23 the release notes seem to imply that apps might need to be changed to use Jakarta imports and dependencies that are compatible with Jakarta APIs.  It's not 100% clear to me that Wildfly 23 and later will still work with Java EE APIs vs Jakarta APIs.  I would recommend you read more on that topic before trying to migrate beyond Wildfly 22.  I could be wrong about that, but based on my reading I have assumed that I can't migrate to Wildfly 23 without changing source code and maven dependencies that use Jakarta EE packages and dependencies.

[Scott Marlow]

FYI, the Java EE 8 APIs are the same as the Jakarta EE 8 APIs (e.g. binary compatible) but switching to compile against the Jakarta EE 8 APIs also sounds fine. 

[Brian Fasano]

Thank you all for your input on this. I'll definitely read through all these and see what happens. 

[Shawn Fox]

My understanding is that the Jakarta project was legally disallowed from using the same package names as Java EE.  When I say APIs, I really meant the namespaces that the APIs are within.  The initial Jakarta release is supposed to be functionally equivalent, but my understanding is that our code will have to be changed to reference an entirely new set of namespaces.  The reason that this is relevant to the thread is that the original poster asked for how to upgrade to Wildfly 24.  Wildfly 22 was the last version of Wildfly containing a statement such as this in the release notes ( WildFly 22 is also a compatible implementation of Java EE 8.).  Wildfly 23 and beyond has no such statement.  I am under the impression that starting with Wildfly 23 that we'll have to recompile my source with Jakarta package names and find version of all maven dependencies built with those Jakarta package names.

Perhaps the release notes for Wildfly 23 are simply confusing as are all of the articles I've read on Jakarta vs Java EE, but it is not clear at all to me how a Java EE8 project can work with Wildfly 23 and later without modification.

[Darran Lofthouse]

At this point in time all WildFly releases are still using the Jakarta EE 8 APIs, it is only presently the "Preview" distributions which have moved to Jakarta EE 9+

[Shawn Fox]

Ok.  I'm sorry I ever mentioned APIs.  I'm going to leave it to the original author to ask any follow ups when he gets past Wildfly 18 and tries to upgrade to Wildfly 23 or later.  I think my question is still misunderstood.  I realize that the Jakarta EE8 APIs are the same as Java 8 APIs by design.  That's not the point.  The point is that the APIs are now packaged within completely different namespaces.  The effort might be fairly trivial, but it seems to me that a JAVA EE8 app is going to have to be recompiled using new package names to get to the APIs.  The import statements will all have to be different.  I have not seen any documentation that implies that JAVA EE8 apps will simply continue to work with Wildfly 23 without modification.  If the original poster is now curious enough to ask follow up questions, then I'll let him do it.  Perhaps I'll need to start my own thread about upgrading to Wildfly 23.

[Wolfgang]

As far as I know, WildFly does some "magic" to convert the "javax" packages to JakartaEE9 equivalents and thus supports old deployments even when running in JakartaEE9 mode: https://www.wildfly.org/news/2020/11/12/Jakarta-EE-9-with-WildFly-Preview/

But this applies only to "WildFly Preview". The regular WildFly release is still JavaEE8, and in JakartaEE8 the packages did not change: https://developers.redhat.com/blog/2019/09/12/jakarta-ee-8-the-new-era-of-java-ee-explained#jakarta_ee_specification_process

Hope this helps

Wolfgang