For many versions, it has been possible to deploy midPoint as a standalone application. After all, this is the preferred way how to do it. Simply run the WAR, using one of the provided scripts or as a service.
There was another way – the legacy way – how to do it. You could take the WAR and deploy it on Tomcat. This was the traditional Java EE way, but it is less and less popular for modern applications. For many versions, deploying WAR to Tomcat has been the deprecated way how to deploy midPoint. In the last released version, midPoint 4.5, it stopped being supported at all.
No more WAR
But the application was still packaged as midpoint.war (binary file in the lib folder).
MidPoint is based on the Spring Boot framework which for many years propagates the idea “make JAR not WAR”. In this spirit, the future binary of midPoint will not be “midpoint.war” but “midpoint.jar”; this will happen in the next version – midPoint 4.6. WAR is sub-optimal packaging provided only for the sake of WAR deployment… that is no longer supported.
There will be no change for users downloading the binary distribution and using scripts or installing a new service. For existing services you will have to replace midpoint.war with midpoint.jar. All this will be described in the release notes for 4.6 in due time. At this moment we just want to assure you that there will be little (but most likely no) change required for standalone deployment.
Temporary snapshot distribution with both WAR and JAR
The final release will bring the distribution you all know, only one file will have “j” instead of “w” in its extension (midpoint.jar).
If you care only about the distribution, you can stop reading now and return to the topic when the release is out.
If someone consumes our snapshot distributions, these will be inflated a bit for a while, as both midpoint.jar and midpoint.war will be provided. This is in part to leave some transition time – albeit only in the development period with snapshots – for downstream builders, e.g. for containerization. The idea is simple – wherever you used midpoint.war previously, use midpoint.jar if you find it in the lib directory. If you copy midpoint.war only and at the same time use one of the provided scripts, it will NOT find the WAR file anymore.
We can’t provide more prescriptive instructions about this as there are many ways how midPoint can be embedded into a container.
WAR or JAR – isn’t it the same?
Both WARs and JARs are “just” glorified ZIP files with a bunch of Java classes, resources and some meta-data. However, their structure is different. You can’t simply rename JAR to WAR and deploy it on Tomcat. Similarly, it requires some effort to make WAR runnable using “java -jar” command. (And we’re gladly skipping many technical details about so-called “fat JARs” as well.)
Guys developing Spring Boot made a lot of effort to support both formats. But they are not created equal. WAR requires more compromises and class/resources loading – and especially searching (“scanning”) – is more efficient when using the JAR structure. This results in some performance gains, which are probably most obvious as faster startup time.
But using JAR also makes our life easier. It is the default packaging of Spring Boot applications. This makes the build pipeline simpler – sometimes it required some effort to keep that WAR packaging alive. No need for it now!
What about overlays?
Obviously, overlays will not be based on the WAR overlay mechanism anymore. Spring Boot repackaging will take over this task – it is used on top of the WAR overlay already anyway. We will document the necessary changes and adapt our provided overlay examples accordingly to be ready around the 4.6 release.
But this should also be a change for the better as the expert builders will be able to utilize more online resources available for Spring Boot applications and not specific to midPoint only.
We hope this change will be a non-event for you. However, it will be definitely symbolic for us at the Evolveum development team.