Also, your settings for the system and server classes for the webapp contexts look all wrong, and don't match the defaults in the WebAppContext class for jetty-9.4.15.
Your dump shows:
System Classes:
+> java.
| | | | | | | +> javax.
| | | | | | | +> org.apache.commons.logging.
| | | | | | | +> org.eclipse.jetty.continuation.
| | | | | | | +> org.eclipse.jetty.http.
| | | | | | | +> org.eclipse.jetty.jndi.
| | | | | | | +> org.eclipse.jetty.plus.jaas.
| | | | | | | +> org.eclipse.jetty.security.
| | | | | | | +> org.eclipse.jetty.server.
| | | | | | | +> org.eclipse.jetty.servlet.
| | | | | | | +> org.eclipse.jetty.servlets.
| | | | | | | +> org.eclipse.jetty.util.
| | | | | | | +> org.eclipse.jetty.websocket.
| | | | | | | +> org.w3c.
| | | | | | | +> org.xml.
"java.", // Java SE classes (per servlet spec v2.5 / SRV.9.7.2)
"javax.", // Java SE classes (per servlet spec v2.5 / SRV.9.7.2)
"org.xml.", // needed by javax.xml
"org.w3c.", // needed by javax.xml
"org.eclipse.jetty.jmx.", // webapp cannot change jmx classes
"org.eclipse.jetty.util.annotation.", // webapp cannot change jmx annotations
"org.eclipse.jetty.continuation.", // webapp cannot change continuation classes
"org.eclipse.jetty.jndi.", // webapp cannot change naming classes
"org.eclipse.jetty.jaas.", // webapp cannot change jaas classes
"org.eclipse.jetty.websocket.", // webapp cannot change / replace websocket classes
"org.eclipse.jetty.util.log.", // webapp should use server log
"org.eclipse.jetty.servlet.DefaultServlet", // webapp cannot change default servlets
"org.eclipse.jetty.jsp.JettyJspServlet", //webapp cannot change jetty jsp servlet
"org.eclipse.jetty.servlets.PushCacheFilter", //must be loaded by container classpath
"org.eclipse.jetty.servlets.PushSessionCacheFilter" //must be loaded by container classpath
Your Server Classes:
| | | | | | | +> -org.eclipse.jetty.apache.
| | | | | | | +> -org.eclipse.jetty.continuation.
| | | | | | | +> -org.eclipse.jetty.http.
| | | | | | | +> -org.eclipse.jetty.jndi.
| | | | | | | +> -org.eclipse.jetty.plus.jass. (note this is misspelt!!)
| | | | | | | +> -org.eclipse.jetty.security.
| | | | | | | +> -org.eclipse.jetty.server.
| | | | | | | +> -org.eclipse.jetty.servlet.
| | | | | | | +> -org.eclipse.jetty.servlets.
| | | | | | | +> -org.eclipse.jetty.util.
| | | | | | | +> -org.eclipse.jetty.websocket.
| | | | | | | +> org.eclipse.jetty.
"-org.eclipse.jetty.server.session.SessionData", //don't hide SessionData for de/serialization purposes
"-org.eclipse.jetty.jmx.", // don't hide jmx classes
"-org.eclipse.jetty.util.annotation.", // don't hide jmx annotation
"-org.eclipse.jetty.continuation.", // don't hide continuation classes
"-org.eclipse.jetty.jndi.", // don't hide naming classes
"-org.eclipse.jetty.jaas.", // don't hide jaas classes
"-org.eclipse.jetty.servlets.", // don't hide jetty servlets
"-org.eclipse.jetty.servlet.DefaultServlet", // don't hide default servlet
"-org.eclipse.jetty.servlet.NoJspServlet", // don't hide noJspServlet servlet
"-org.eclipse.jetty.jsp.", //don't hide jsp servlet
"-org.eclipse.jetty.servlet.listener.", // don't hide useful listeners
"-org.eclipse.jetty.websocket.", // don't hide websocket classes from webapps (allow webapp to use ones from system classloader)
"-org.eclipse.jetty.apache.", // don't hide jetty apache impls
"-org.eclipse.jetty.util.log.", // don't hide server log
"-org.eclipse.jetty.alpn.", // don't hide ALPN
"org.objectweb.asm.", // hide asm used by jetty
"org.eclipse.jdt.", // hide jdt used by jetty
"org.eclipse.jetty." // hide other jetty classes
There is also something else wrong with the setup for your contexts, as you can see by the logs that for the contexts /service and /, that jetty tries to load the JettyJspServlet, fails and replaces it with the NoJspServlet:
NO JSP Support for /service, did not find org.eclipse.jetty.jsp.JettyJspServlet
NO JSP Support for /, did not find org.eclipse.jetty.jsp.JettyJspServlet
However, for the /zxxxxAdmin context, we don't see the failure to load the JettyJspServlet early in deployment, it only fails to load it when the ServletHandler is being started. I assume this failure is due to your incorrect system and server classes setup, however this should also fail for the / and /service contexts. The fact that it doesn't means there is something else wrong with your setup.
As for the /zimlet context, this appears to be differently deployed than the rest - I see it is an auto-managed bean of the ContextHandlerCollection, whereas the rest of the contexts are added as managed beans of the ContextHandlerCollection. Please provide more details on how you are deploying the /zimlet context.
Jan