How do I configure embedded jetty to used war file in executable jar as resource

Question

I have an executable jar with a war file in it. Running the jar extracts the war file and creates a WebAppContext from it using webAppContext.setWar(warFile). Although that works, it seems that webAppContext.setWarResource(warResource) should work. I've tried it creating a resource using new PathResource("file.war") which shows a path like "jar:file:/Users/.../jetty-1.0.0-jar-with-dependencies.jar!/file.war". Sounds promising and conventional, but when I try it I get "java.lang.IllegalArgumentException: not file: scheme". Do I really have to extract the war file or is there a trick?

Answer 1

That would be a nested jar content reference and no Java program can do that.

Option 1: use a live-war (aka an executable-war) instead.

This would be a war file that can be deployed traditionally if you want to, but can also be used standalone from the java command line (and will start it's own server if it needs to).

An example project is maintained by the Eclipse Jetty project at ... https://github.com/jetty-project/embedded-jetty-live-war

Note: the live-war concept was inspired by work done by the Jenkins project and their live-war.

Option 2: eliminate the WAR file layer entirely in your JAR

Don't package the WAR contents in your JAR as a filename.war, consider using it as an exploded WAR (or war directory) instead.

Just unpack the WAR into your JAR file somewhere safe (like /META-INF/webapps/<app-id>/) and then reference that directory location in your JAR file instead.

Option 3: eliminate the need for the WAR concepts entirely

This is the number one most popular choice.

You deconstruct your WAR file into a ServletContextHandler with configured Servlets and Filters, this also eliminates the need for things like annotation scanning / bytecode scanning (which is quite complicated), you'll also not have to wrangle the nested / isolate classloader (your uber JAR file contains all of the classes and downstream dependencies needed to run your webapp), and this approach will definitely speed up your startup time.