EAP 7 XP bootable jar in OCP 4

Environment

• Red Hat JBoss Enterprise Application Platform (EAP)
  • 7.x
• OpenJDK 8, OpenJDK 11, OpenJDK 17
• Red hat OpenShift Container Platform (OCP)
  • 4.x

Issue

• How to build an EAP 7 XP bootable jar in OCP 4?
• What are the limitations for this process?

Resolution

EAP 7 XP is supported as bootable jar and can be deployed in OCP 4, as explained on EAP 7 XP - using bootable jar. Only EAP 7 XP is supported as bootable jar not EAP 7 per se.

Bootable jar definition

Bootablejar is a jar that contains everything that it needs to work and a deployment container - basically is able to start/run only with a jar with java -jar bootable.jar. And by definition a WAR is not bootable - a war requires to be deployed in a servlet container. Given that's a jar, jar properties, like manifest file apply. The EAP 7's XP bootable jar will generate one war and one jar, the jar is the bootable EAP 7 and when deployed it will have the jar inside.

EAP 7

EAP 7 is not supported as bootable jar, as of this moment as bootable jar regardless of the method; Only EAP 7 XP supports bootable jar.

Streamlining the war/jar creation

During the compilation process, one war and one jar will be created and this is expected.
The compilation of the EAP 7 XP as bootable jar will result in a war and a jar - and that's correct and expected.
That's because the war is the primary artifact that has been built during the maven compile/package. This war is automatically deployed inside the bootable JAR. So not needed to deploy the war inside the jar later on.

EAP XP lifecycle clarification

For EAP XP lifecycle see JBoss Enterprise Application Platform expansion pack (JBoss EAP XP or EAP XP. In this note, EAP XP has a shorter lifecycle because the Microprofile specs are evolving much quicker, 3 or 4 times a year they release spec updates, so EAP XP has a shorter lifecycle than EAP 7.

hollow jar option

We have also the "hollow jar" notion. A maven pom.xml with packaging "pom" and no application. It will build a bootable jar with no deployment in it. You can, at runtime provide an option with the war to deploy at runtime. That could be interesting when building custom images for example - trimmed images - depending on the pipeline.
User can use JAVA_ARGS="--deployment=/deployments/myapp.war" if want to reuse the layer that contains the Bootable JAR, then produce an Hollow Jar in a shared layer.

Then add a layer with their application (let's say in /deployments/myapp.war)

About support

Technically the manual build is not supported - we can look into it on commercial reasonable effort given it is quite trivial, but not technically supported.
The supported methods would be binary build/S2I.
In other words, that if one uses openjdk image, and copy the bootable JAR in /deployments it is not really supported, however, that is expected to work properly and we would fix bugs found in this context - if there is any bug, for that matter.

Root Cause

Galleon can be used to trim the EAP 7 image and create slim/thin images or bootable jar. One uses a list of subsystems to add the functionality.
For bootable jar one needs a pom defining the layers at feature-pack.
Wheareas the Galleon provisioning is either at S2I environment level, or via Galleon's provioning.xml.

FAQ:

Q1. Can I do a bootable jar with a war instead?
A1. No. A war by definition is not bootable and requires a servlet container to start. A war application can be converted to bootable jar (which is EAP/Servlet Container/etc along with the application inside of the bootable jar), which is then bootstrapped by the JDK. See the Root Cause for details.

Q2. Can I change the OpenJDK image to start a war?
A2. No. A war needs a servlet container to start. No dockerfile or script will bypass that, you need the servlet container, like EAP or tomcat. See the Root Cause for details.

Q3. I don't want to use a servlet container - meaning I want to avoid EAP and tomcat - what are the options in Java?
A3. Not use a war, you can use a jar (or bootable jar). See the first reply for details. If you want a java application you need either a bootable jar or a war deployed in a servlet container.

Q4. What is bootable jar?
A4. A bootable jar is a jar that contains everything that it needs to work and a deployment container <-- important part.

Q5. What is EAP XP bootable jar?
A5. EAP XP bootable jar would be Similar to Spring Boot, except instead of starting tomcat/jetty/undertow, we start EAP which includes undertow.

Q6. How to do this: "java -jar app.war" inside a pod?
A6. It cannot work. A war file is not bootable, therefore needs a deployment servlet to work. One deploys a .war file, doesn't boot a war file.

Q7. I've found a reference Content from www.logicbig.com is not included.Spring-boot bootable war that executes a war as a jar: java -jar app.war
A7. That's a non standard solution and work because it is not technically a war - the structure used is a jar - and this is de facto renaming a jar a war. A jar and a war have a respective structure and one can bend that structure. If you use a jar definition and add web contents on it, and make the servlet container start before to fetch the WEB-INF. In other works, it embedded a tomcat and it will start tomcat which will look in WEB-INF and add a bypassing mechanism there to make it work using a jar structure.

Q8. From example Content from docs.wildfly.org is not included.docs wildfly - bootable jar there is a war being executed, how come?
A8. One can build a hollow bootable jar and set a war deployment with it as below [see below]. On this case, the bootable jar starts the server deployment container and the war is deployed in the sequence. This was invented exactly to bypass the rule of a java -jar not being able to execute a war file [below] because it needs a deployment server:

java -jar target/jaxrs-hollow-server-bootable.jar --deployment=path/to/my-jaxrs-app.war

Q9. Can I go right now and create a dockerfile to make a openjdk (aka java; with a ubi image basis) to execute a war file with: "java -jar app.war"?
A9. No. A dockerfile can add, removed, edit images, but one cannot force java to execute "java -jar app.war" with an actual war file. One could create a war file, rename it jar, and execute, but it won't work. Dockerfile is used for customizations: one can create a tomcat image, with openjdk, with certain packages; or a bootable jar with jre or jdk. Dockerfile cannot bypass the inherent rules of the language/mechanic of the language.

Q10. Can wildfly-ee-galleon-pack 7.4.x be used to build Bootable JAR?
A10. wildfly-ee-galleon-pack 7.4.x alone can't be used to build Bootable JAR. You need wildfly-galleon-pack.

Q11. What are the layers to trim the EAP 7?
There is a complete list of basic layers and foundations layers (decorator layers). A small sample JBoss EAP 7 thin image. If you don't add any layer all layers are bought and the image will be fat.

Diagnostic Steps

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.