I'm currently in the process of creating a web service to be deployed onto an existing Jetty 9 server. I decided to use maven to handle the dependency management for this application and it is creating a bit of a problem. When I try to start the app, it is failing due to library conflicts. I figured out that the source of the problem is that the classpath is including both my maven dependencies and the jars in $JETTY_HOME/lib/ext/. I can't simply rename or delete lib/ext since there are existing applications on the server that depend on those libraries.
Is there a way to configure jetty to include or exclude lib/ext from the classpath on a per-application basis? If not, is there some other way I can work around this problem?
TL;DR - I don't think there is a simple answer.
According to the documentation, the jars in the lib/ext directory are added to the classpath by the "ext" module. So, you could in theory disable the "ext" module. But that will remove the jars from the classpath for all of the web services in the container. So that won't work ... except for testing purposes.
So that leaves you with a couple of more drastic solutions:
Set up a separate Jetty server to run the new webapp. (For example, using Docker containers.)
Analyze the other webapps to determine which of them use the JARs in the lib/ext directory, and rebuild their WARs so that (at least) the conflicting dependencies are in the WARs that need them rather than in lib/ext.
This is probably what you should do.
Go on a Jetty code hacking spree and modify the way that Jetty builds the "server" classpath. Anything is possible, if you are prepared to put in enough coding effort. But you will be creating "technical dept" for yourself by (in effect) creating a private fork of Jetty. So this is a really bad idea.