Meecrowave: which packaging for production?

Apache Meecrowave is really a flexible solution for JAX-RS/CDI applications. However when it comes to production the question of the packaging will pop up. Here how to tackle it.

Production needs

Before seeing how to answer to the packaging let see what are common needs and what you can need to take into account during this selection phase.

• monitoring: production often need some monitoring. The simplest one is a "ping" servlet answering a HTTP 200 (OK) to communicate to the monitoring client the application works. A more advanced flavor can take into account datasources etc...but technically it stays the same. It often leads to the "ops" team being able to add to the deployed classpath a jar without requiring the "dev" team to add it itself.
• logging: production often requires that the logging is configured outside the application (physically) and configurable by an "ops" team to be able to aggregate the logs in a specific tool like Splunk.
• scanning: another common need is to be able to scan applications for security issues identification and upgrades (if "foo-bar.jar" is known as affected it needs to be upgradable easily to the version fixing it and potentially automatically by ops team if not a version affecting the development)
• deployment: here the constraints depends the teams but generally you want to be able to have one artifact (whatever it is) and replace the old folder/file by the new one on redeployment. Understand by that you don't want to have to build an advanced diff to be able to redeploy the application.
• starting/stopping: here the need is just to have a service tool like to manage the instance (start/stop commands)

Meecrowave options

Meecrowave has several options to package an application but all will not fit these needs - they are not useless however because they fit standalone applications, demos, and a few other cases.

Here are the options we'll investigate:

• fatjar/uber jar: you take the whole application and put it in a single .jar
• jar: plain flat classpath application but not aggregated in a single jar
• war: you create a web application like one you would deploy in a servlet container
• custom assembly: you create a custom instance zip setup
• meecrowave bundle: meecrowave option to create a zip instance

Fatjar

Criteria	Conclusion
Monitoring	This is not that easy if the application didn't plan it and can require ops team to not respect the scripts to move to a plain jar style scripts. However it is doable if the application launching doesn't assume there is a single jar for its own purposes (it can be done for scanning rarely).
Logging	The JVM can have log4j2 configuration through system properties so it matches the requirements.
Scanning	The security scanning is pretty much impossible without opening the jar to see what is inside and then must assume the pom metadata are not stripped during the bundling which is not guaranteed. This is not a very comfortable solution for the ops.
Deployment	Just replacing the jar is enough so this is smooth.
Scripts	java -jar app.jar

Jar

Criteria	Conclusion
Monitoring	A plain classpath is used so it is easy to add another folder to it. You can also rely on meecrowave sharedLib option for this particular need.
Logging	The JVM can have log4j2 configuration through system properties so it matches the requirements. A configuration folder is also usable if added to the classpath.
Scanning	The lib folder is scannable easily once identified somehow.
Deployment	Just replacing the application folder is the easiest. Only constraint is there is no storage in these folders but it is a good practise to not do it anyway.
Scripts	java -cp $(echo lib/*.jar | tr ' ' ':') org.apache.meecrowave.runner.Cli

War

Criteria	Conclusion
Monitoring	The container classpath can get more jars so this is close to the jar solution. However it is harder to get access to application classes and can need some container glue code (vs standard code with the jar flavor).
Logging	The JVM can have log4j2 configuration through system properties so it matches the requirements.
Scanning	The scanning is close to the jar solution unpackging the war file but you need to scan also the container folder so it makes a bit more scanning work depending the tool you use.
Deployment	Just replacing the war and cleaning the unpackged folder is enough.
Scripts	java -jar meecrowave-runner.jar -webapp app.war

Assembly

The matching of the requirements fully depends how the packaging is done but nothing prevents to match them. This will however not be standard or easy to share accross applications.

Meecrowave bundle

This solution relies on meecrowave maven plugin and the goal meecrowave:bundle. It can produce a zip and/or a tar.gz with a standarized layout based on tomcat. It mainly relies on a classpath deployment but nothing prevents you to deploy a war.

Criteria	Conclusion
Monitoring	There is a defined lib folder so it is easy to do.
Logging	The log4j2 configuration is placed in conf/ folder of the instance.
Scanning	The library folder being standardized it is easy to handle.
Deployment	Replacing the whole unarchived folder is the way to go.
Scripts	Bash scripts are provided to start/stop the instances based on tomcat ones.

Conclusion

All packaging solutions have their pro and cons but the meecrowave bundle one allows to be close to a tomcat instance which is generally a good thing for ops teams. It also allows to standardize how you interact with an instance and where you can check the configuration which is very appreciated at 2am in the night when you get a call saying you need to check what happent on an instance ;).