Web applications are often deployed into some kind of web server or web container like Wildfly, Tomcat, Apache or IIS. For single-instance services this can be overkill and serving requests can easily be done in-process without interfacing with some external web container or web server.
A proven and popular framework for an in-process web container and webserver is Eclipse Jetty for Java. For easy deployment and distribution you can build a single application archive containing everything: the static resources, web request handling, all your code and dependencies needed to run your application.
If you package your application that way there is one caveat when trying to serve static resources from this application archive. Let us have a look how to do it with Jetty.
Using the DefaultServlet for static resources on the file system
Jetty comes with a Servlet-Implementation for serving static resources out-of-the-box. It is called DefaultServlet and can be used like below:
Server server = new Server();
ServerConnector connector = new ServerConnector(server);
connector.setHost(listenAddress);
connector.setPort(listenPort);
server.addConnector(connector);
var context = new ServletContextHandler();
context.setContextPath("/");
var defaultServletHolder = context.addServlet(DefaultServlet.class, "/static/*");
defaultServletHolder.setInitParameter("resourceBase", "/var/www/static");
server.setHandler(context);
server.start();
This works great in the case of static resources available somewhere on the filesystem.
But how do we specify where the DefaultServlet can find the resources within our application archive?
Using the DefaultServlet for static in-JAR resources
The only thing that we need to change is the init-parameter called resourceBase from a normal file path to a path in the JAR. What does a path to the files inside a JAR look like and how do we construct it? It took me a while to figure it out, but here is what I came up with and it works perfectly in my use cases:
private String getResourceBase() throws MalformedURLException {
URL resourceFile = getClass().getClassLoader().getResource("static/existing-file-inside-jar.txt");
return new URL(Objects.requireNonNull(resourceFile).getProtocol(), resourceFile.getHost(), resourceFile.getPath()
.substring(0, resourceFile.getPath().lastIndexOf("/")))
.toString();
}
The method results in a string like jar:file:/path/to/application.jar!/static. Using such a path as the resourceBase for the DefaultServlet allows you to serve all the stuff from the /static directory inside your application (or any other) jar containing the class this method resides in.
A few notes on the code
Why don’t we just hardcode a path after the jar:-protocol? Well, the file path may chance in several scenarios:
- Running the application on a different platform or operating system
- Renaming the application archive – it could contain the version number for example…
- Installing or copying the application archive to a different location on the file system
Using an existing resource and reusing the relevant parts of the URL-specification for the resource base directory solves all these issues because it is computed at runtime.
However, the code assumes that there is at least one resource available in the JAR and that its path is known at compile time.
In newer JDKs like 21 LTS constructing an URL using the constructor is deprecated but I did not bother to rewrite the code to use URI because of time constraints. That is left up to you or a future release…
As always I hope someone finds the code useful and drops a comment.
Schneide Blog 