joakime
commented
2 years ago Some things that stand out ...
Keep in mind that Jetty 10+ jar files have valid module-info.class files. This means the JVM access rules for what's in the JAR files are different than Jetty 9 and older. This is important to recognize.
Don't use a jar-with-dependencies with a WebApp / WAR based context. WebApp rules on packaging are super strict and about how components are found/discovered.
Don't use META-INF/MANIFEST.MF based jar dependencies, there are too many bugs in Java 9+ with jars that have module-info.class files (or that use MultiRelease Jar files).
Either use a ServletContextHandler (instead of a WebAppContext) if you insist on using a jar-with-dependencies, or if just must use a WebAppContext then use an executable "live" war file (to maintain that uber behavior that some jar-with-dependencies configurations have).
- Uber-jar with ServletContextHandler example -> https://github.com/jetty-project/embedded-jetty-uber-jar
- Self executing "live" War File example -> https://github.com/jetty-project/embedded-jetty-live-war
The URI reference you have has an invalid syntax.
jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/staticThat's a badly formatted URI, like what is seen from the buggy java.io.File class.
The correct syntax should be ...
jar:file:///usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/staticYour technique for obtaining the webDir is unreliable.
String webDir = this.getClass().getClassLoader().getResource("static").toExternalForm();Requesting a directory via .getResource(String) is unreliable across JVMs.
It would be best to always request a file, and then resolve to the directory.
Eg: if you have a /static/index.html, then use .getResource("static/index.html") and then clean up the resulting URL (tip: use URI.resolve("./"))
Break up your webDir setup. It will be different in the IDE vs standalone, as you are not bundled into a JAR in the IDE.
String webDir = this.getClass().getClassLoader().getResource("static").toExternalForm();
WebAppContext waContext = new WebAppContext(webDir, "/"); For starters, when in your IDE, you are not executing in a JAR, esp a jar-with-dependencies, so that means you don't have jar:file:// reference ever, and your classpath will need to be built from where the IDE is storing the components you need. So that means using WebAppContext.setBaseResource() and WebAppContext.setExtraClassPath() when in your IDE.
For production, you use WebAppContext.setWar() only.
to something like ...
WebAppContext context = new WebAppContext();
context.setContextPath("/");
switch (getOperationalMode())
{
case PROD:
// Configure as WAR
context.setWar(basePath.toString());
break;
case DEV:
// Configuring from Development Base
context.setBaseResource(new PathResource(basePath.resolve("src/main/webapp")));
// Add webapp compiled classes & resources (copied into place from src/main/resources)
Path classesPath = basePath.resolve("target/thewebapp/WEB-INF/classes");
context.setExtraClasspath(classesPath.toAbsolutePath().toString());
break;
default:
throw new FileNotFoundException("Unable to configure WebAppContext base resource undefined");
}Depending on the style of "jar-with-dependencies" you are using, it could easily be incompatible with org.eclipse.jetty.server.webapp.ContainerIncludeJarPattern.
If you are using the META-INF/MANIFEST.MF based dependencies, then the pattern is very likely not going to work, as Jetty is unable to see into the system classloader entries reliably on Java 9+ based JVMs (it can work on some systems, not on others). If you are using any kind of uber jar with your jar-with-dependencies configuration, then you have no container JARs to configure.
You have no webdefault.xml being used.
org.eclipse.jetty.servlet.ServletHandler$Default404Servlet-5dc3fcb7That says you are using the bare-bones WebAppContext, it doesn't even have a typical DefaultServlet, and has been setup for Default404Servlet which will always return a 404.
This is problem with your jar-with-dependencies again. It's messed up your access within the jetty-http jars.
StefanViljoen
sbordet
lorban
Jetty Version: Jetty 10.0.0 up to Jetty 11.0.11 inclusive
Java Vendor: java version "17.0.4.1" 2022-08-18 LTS Java(TM) SE Runtime Environment (build 17.0.4.1+1-LTS-2) Java HotSpot(TM) 64-Bit Server VM (build 17.0.4.1+1-LTS-2, mixed mode, sharing
Operating system: Linux, Ubuntu 20.04 LTS
Description:
In a .jar with an embedded Jetty from version 10.0.0 and up, the WebAppContext class cannot parse resources inside the same JAR Jetty is embedded in specified in the format "jar:file:..."
All HTTP requests received by the server for any web content inside the JAR in which Jetty is embedded fail with 404 not found.
Regressing Jetty back to, for example, 9.4.48.v20220622, and jar:file references are again parsed by the WebAppContext class in the Jetty instance embedded in the same JAR file.
How to reproduce:
In the JAR from which the embedded Jetty instance runs, there is a "static" folder in the root of the jar.
The "static" folder contains an index.html to render.
The JAR must be run in a detached JRE - not inside an IDE because it functions correctly as long as run inside the IDE (Netbeans 14 in my case) as the WebAppContext contextPath then becomes file:///... instead of jar:file:...
Code - WebHost.java:
With
"webDir" = jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static
for 127.0.0.1:8086/index.html
Jetty 10.0.0 and up returns
Regress to latest Jetty 9, above works correctly, and
jar:file:/usr/src/verdi/verdi-12-JDK17-jar-with-dependencies.jar!/static
can be resolved by the WebAppContext class, in a detached JRE, separate from the IDE, under Linux.