This question already has answers here:
Servlet 5.0 JAR throws compile error on javax.servlet.* but Servlet 4.0 JAR does not
(3 answers)
Closed 1 year ago.
I'm having a problem with my first Web Application. I use IntelliJ as IDE and Tomcat as Webserver.
Every servlet I've tried to acces, throws an 404 Error. Even if I copy some youtube tutorials, which seems to work like a charm.
The button in the form sends me to: http://localhost:8080/IUBHQuiz/login
Can you tell me whats wrong? I am going nuts.
login.java
package com.example.IUBHQuiz;
import java.io.*;
import javax.servlet.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
import java.sql.*;
#WebServlet("/login")
public class login extends HttpServlet {
#Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
String email = request.getParameter("fmail");
String pass = request.getParameter("fpw");
if(email.equals("j") && pass.equals("j"))
{
RequestDispatcher rs = request.getRequestDispatcher("/main.jsp");
rs.forward(request, response);
}
else
{
out.println("Username or Password incorrect");
RequestDispatcher rs = request.getRequestDispatcher("/index.jsp");
rs.include(request, response);
}
out.close();
}
index.jsp
<%# page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
<!DOCTYPE html>
<html>
<head>
<title>IUBH Quiz</title>
<link href="./resources/css/style.css" rel="stylesheet">
</head>
<body>
<div class="main">
<div class="image-container">
<img src="./resources/images/logo.png" alt="Logo">
</div>
<div class="Login">
<h1>Willkommen beim IUBH-Quiz!</h1>
<form action="login" method="post">
E-Mail:<input type="text" id="fmail" name="fmail"><br><br>
Passwort: <input type="password" id="fpw" name="fpw"><br><br>
<input type="submit" value="Log In" class="button">
</form>
</div>
<div class="Links">
Passwort vergessen
Registrieren
</div>
</div>
</body>
</html>
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
</web-app>
For copyright reasons the Servlet 5.0 API (implemented by Tomcat 10) and the Servlet 4.0 API (implemented by Tomcat 9) are incompatible: the API namespace changed from javax.* to jakarta.*. This can manifest in many ways:
Software written for Servlet 4.0 does not compile against the API jars from Tomcat 10: cf. Servlet 5.0 JAR throws compile error on javax.servlet.* but Servlet 4.0 JAR does not,
Servlet 4.0 applications which use a web.xml descriptor throw a lot of ClassNotFoundExceptions and don't start: cf. Tomcat 10.x throws java.lang.NoClassDefFoundError on javax/servlet/ServletRequestListener.
Servlet 4.0 applications which use a web.xml descriptor log a "X is not a jakarta.servlet.Servlet" error: cf. Servlet class org.restlet.ext.servlet.ServerServlet is not a jakarta.servlet.Servlet.
Servlet 4.0 applications which use annotations to declare servlets stop working, as in your case,
Servlet 4.0 applications which rely on a ServletContainerInitializer (like Spring and Spring Boot applications) don't start: cf. Deploying Spring MVC 5 on Tomcat 10 … deployment problems
The last one is the hardest to diagnose: no errors are written to the log files, but the application doesn't work. The reason behind this behavior is that #javax.servlet.WebServlet annotations are ignored: the server is scanning for #jakarta.servlet.WebServlet.
Since all three problems have the same cause, the solutions provided to the aforementioned questions all work. In this specific case I would advise to use the Tomcat Migration Tool for Jakarta EE.
Remark: The Tomcat download site features a warning, that unfortunately many people don't notice:
Users of Tomcat 10 onwards should be aware that, as a result of the move from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later.
I had the same issue while reproducing the problem reported at IntelliJ IDEA forums.
It didn't work with Tomcat 10 for the reasons described in the answer by Piotr P. Karwasz, but it works just fine with Tomcat 9.0.44 and earlier versions.
Related
This question already has answers here:
Servlet 5.0 JAR throws compile error on javax.servlet.* but Servlet 4.0 JAR does not
(3 answers)
Closed 1 year ago.
I'm having a problem with my first Web Application. I use IntelliJ as IDE and Tomcat as Webserver.
Every servlet I've tried to acces, throws an 404 Error. Even if I copy some youtube tutorials, which seems to work like a charm.
The button in the form sends me to: http://localhost:8080/IUBHQuiz/login
Can you tell me whats wrong? I am going nuts.
login.java
package com.example.IUBHQuiz;
import java.io.*;
import javax.servlet.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
import java.sql.*;
#WebServlet("/login")
public class login extends HttpServlet {
#Override
protected void doPost(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
response.setContentType("text/html;charset=UTF-8");
PrintWriter out = response.getWriter();
String email = request.getParameter("fmail");
String pass = request.getParameter("fpw");
if(email.equals("j") && pass.equals("j"))
{
RequestDispatcher rs = request.getRequestDispatcher("/main.jsp");
rs.forward(request, response);
}
else
{
out.println("Username or Password incorrect");
RequestDispatcher rs = request.getRequestDispatcher("/index.jsp");
rs.include(request, response);
}
out.close();
}
index.jsp
<%# page contentType="text/html; charset=UTF-8" pageEncoding="UTF-8" %>
<!DOCTYPE html>
<html>
<head>
<title>IUBH Quiz</title>
<link href="./resources/css/style.css" rel="stylesheet">
</head>
<body>
<div class="main">
<div class="image-container">
<img src="./resources/images/logo.png" alt="Logo">
</div>
<div class="Login">
<h1>Willkommen beim IUBH-Quiz!</h1>
<form action="login" method="post">
E-Mail:<input type="text" id="fmail" name="fmail"><br><br>
Passwort: <input type="password" id="fpw" name="fpw"><br><br>
<input type="submit" value="Log In" class="button">
</form>
</div>
<div class="Links">
Passwort vergessen
Registrieren
</div>
</div>
</body>
</html>
web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
version="4.0">
</web-app>
For copyright reasons the Servlet 5.0 API (implemented by Tomcat 10) and the Servlet 4.0 API (implemented by Tomcat 9) are incompatible: the API namespace changed from javax.* to jakarta.*. This can manifest in many ways:
Software written for Servlet 4.0 does not compile against the API jars from Tomcat 10: cf. Servlet 5.0 JAR throws compile error on javax.servlet.* but Servlet 4.0 JAR does not,
Servlet 4.0 applications which use a web.xml descriptor throw a lot of ClassNotFoundExceptions and don't start: cf. Tomcat 10.x throws java.lang.NoClassDefFoundError on javax/servlet/ServletRequestListener.
Servlet 4.0 applications which use a web.xml descriptor log a "X is not a jakarta.servlet.Servlet" error: cf. Servlet class org.restlet.ext.servlet.ServerServlet is not a jakarta.servlet.Servlet.
Servlet 4.0 applications which use annotations to declare servlets stop working, as in your case,
Servlet 4.0 applications which rely on a ServletContainerInitializer (like Spring and Spring Boot applications) don't start: cf. Deploying Spring MVC 5 on Tomcat 10 … deployment problems
The last one is the hardest to diagnose: no errors are written to the log files, but the application doesn't work. The reason behind this behavior is that #javax.servlet.WebServlet annotations are ignored: the server is scanning for #jakarta.servlet.WebServlet.
Since all three problems have the same cause, the solutions provided to the aforementioned questions all work. In this specific case I would advise to use the Tomcat Migration Tool for Jakarta EE.
Remark: The Tomcat download site features a warning, that unfortunately many people don't notice:
Users of Tomcat 10 onwards should be aware that, as a result of the move from Java EE to Jakarta EE as part of the transfer of Java EE to the Eclipse Foundation, the primary package for all implemented APIs has changed from javax.* to jakarta.*. This will almost certainly require code changes to enable applications to migrate from Tomcat 9 and earlier to Tomcat 10 and later.
I had the same issue while reproducing the problem reported at IntelliJ IDEA forums.
It didn't work with Tomcat 10 for the reasons described in the answer by Piotr P. Karwasz, but it works just fine with Tomcat 9.0.44 and earlier versions.
I'm creating my first project Java EE 7, but I'm having trouble. Appreciate any help.
Tomcat 7.0.34
JSF 2.2
Primefaces 3.5
javaee-api-7.0.jar
When the application start, the Tomcat log shows the following message:
"validateJarFile (C:\...\build\web\WEB-INF\lib\javaee-api-7.0.jar)-jar not loaded. See Servlet 2.3 Spec, section 9.7.2. Offending class: javax/servlet/Servlet .class"
when I click on the button that calls the managed bean, I get the error:
Advertência: /index.xhtml #18,66 value="#{indexMB.user}": Target Unreachable, identifier 'indexMB' resolved to null
javax.el.PropertyNotFoundException: /index.xhtml #18,66 value="#{indexMB.user}": Target Unreachable, identifier 'indexMB' resolved to null
IndexMB
#Named("indexMB")
#RequestScoped
public class IndexMB {
private String password;
private String user;
public String loginTest(){
return (this.user.equals("admin") ? "adminPage" : "inOutPage");
}
// getters and setters
}
index.xhtml
<html ...>
<f:loadBundle basename="i18n" var="bundle" />
<h:head>
<title>#{bundle['index_title']}</title>
</h:head>
<h:body>
#{bundle['index_appname']}
<br />
<h:form id="frmIndex">
<p:panelGrid columns="2">
<p:outputLabel for="user" value="#{bundle['lblUser']}" />
<p:inputText id="user" value="#{indexMB.user}" />
<p:outputLabel for="password" value="#{bundle['lblPassword']}" />
<p:password id="password" value="#{indexMB.password}" />
</p:panelGrid>
<p:commandButton action="#{indexMB.loginTest}" value="#{bundle['btn_login']}" />
</h:form>
</h:body>
faces-config.xml
<?xml version='1.0' encoding='UTF-8'?>
<faces-config version="2.2"
xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-facesconfig_2_2.xsd">
<application>
<locale-config>
<default-locale>pt_BR</default-locale>
<supported-locale>en</supported-locale>
<supported-locale>fr</supported-locale>
</locale-config>
</application>
These topics have not helped me:
Java EE 6 #javax.annotation.ManagedBean vs. #javax.inject.Named vs. #javax.faces.ManagedBean
Target Unreachable identifier resolved to null
Target Unreachable, identifier resolved to null
javax.el.PropertyNotFoundException : Target Unreachable, identifier 'login' resolved to null Spring + JSF
http://www.andrejkoelewijn.com/blog/2010/03/05/jee-cdi-tip-target-unreachable-identifier-resolved-to-null/
Tomcat as being a barebones JSP/Servlet container doesn't support CDI out the box. It is not correct to drop jakartaee-api.jar or javaee-api.jar in /WEB-INF/lib just to get your code to compile. The JEE API JAR contains solely the API classes, not the concrete implementation. Get rid of the whole JAR. It can cause many other portability troubles like as the ones described in this answer: How do I import the javax.servlet / jakarta.servlet API in my Eclipse project? You should actually be installing the concrete implementation along with the specific API.
You have 2 options:
Drop Tomcat and go for a true Jakarta EE container. As you're using Tomcat, just step over to TomEE. It's really simple, download the TomEE web profile zip file, extract it and integrate it in Eclipse exactly the same way as you did for Tomcat. Don't forget to remove the Jakarta EE JAR file from webapp and alter the Targeted Runtime property in project's properties from Tomcat to TomEE so that Jakarta EE dependencies are properly resolved. See also What exactly is Java EE?
No additional JARs or configuration is necessary. You can even remove the manually installed JSF/JSTL/CDI/BV/JPA/EJB/JTA/JSONPJAX-RS/etc/etc libraries from your webapp. TomEE as being a true Jakarta EE container already provides them all out the box. In case you're using Maven, the below coordinate is sufficient.
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-web-api</artifactId>
<version><!-- e.g. 10.0.0 or 9.1.0 --></version>
<scope>provided</scope>
</dependency>
Note the importance of provided and its meaning as in "the target runtime already provides this out the box". See also How to properly configure Jakarta EE libraries in Maven pom.xml for Tomcat? for detailed pom.xml examples of Tomcat and normal JEE containers.
If you want to stick to Tomcat, then you need to manually install a true CDI implementation via the webapp. Below instructions assume Tomcat 10+. Weld is one of the available CDI implementations. In the Weld installation guide you can find instructions how to integrate it in Tomcat. For sake of completeness and future reference, here are the steps:
For Tomcat 10.1.x, drop the weld-servlet-shaded.jar of version 5.x in webapp's /WEB-INF/lib. In case you're using Maven, use this coordinate:
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet-shaded</artifactId>
<version>5.1.0.Final</version>
</dependency>
For Tomcat 10.x, use weld-servlet-shaded.jar of version 4.x instead:
<dependency>
<groupId>org.jboss.weld.servlet</groupId>
<artifactId>weld-servlet-shaded</artifactId>
<version>4.0.3.Final</version>
</dependency>
Optionally, create a /META-INF/context.xml file in webapp with following content:
<Context>
<Resource name="BeanManager"
auth="Container"
type="jakarta.enterprise.inject.spi.BeanManager"
factory="org.jboss.weld.resources.ManagerObjectFactory"/>
</Context>
This step is is only necessary when the CDI-dependent library tries to manually find it in JNDI. This step is not necessary when you're using for example Jakarta Faces / JSF version 2.3 or newer.
Create a /WEB-INF/beans.xml file in webapp to trigger activation of CDI. It can be kept empty.
That's it.
In case you prefer OpenWebBeans above Weld as CDI implementation, or need to install CDI in Tomcat 9.x or older, head to this blog for detailed Maven installation instructions: How to install CDI in Tomcat?
Other possible option is leaving beans.xml in your deployment.
Can you tell me how to know which servlet and JSP version am I using ?
I use NetBeans IDE 7.1.2 for creating Servlets and JSP.
You can easily check the JSP,SERVER and SERVLET version. Add the following code in your jsp page after that run using any IDE Tools.
Server Version: <%= application.getServerInfo() %><br>
Servlet Version: <%= application.getMajorVersion() %>.<%= application.getMinorVersion() %>
JSP Version: <%= JspFactory.getDefaultFactory().getEngineInfo().getSpecificationVersion() %> <br>
You can get the details programatically using ServletContext #getMajorVersion() and #getMinorVersion().
For knowing the JSP version corresponding to the Servlet, you can get details from this Tomcat page.
Below is a brief summary (check Tomcat's corresponding version at the link above):
Servlet 4.0 uses JSP 2.3
Servlet 3.1 uses JSP 2.3
Servlet 2.5 uses JSP 2.1
Servlet 2.4 uses JSP 2.0
Servlet 2.3 uses JSP 1.2
Servlet 2.2 uses JSP 1.1
Servlet 2.1 uses JSP 1.0
The version is declared in the web.xml file using the attribute version.
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5">
...
</web-app>
Read more
I'm trying to deploy a very simple Struts app on WebLogic 11gR1. The app has one JSP called Welcome.jsp and this JSP contains the following tag :
<bean:cookie name="" id=""/>
The associated taglib is imported at the top of the JSP using the following line :
<%# taglib uri="http://struts.apache.org/tags-bean" prefix="bean" %>
When this tag is inside the JSP, I've the following error :
Welcome.jsp:11:24: javax.servlet.http.Cookie cannot be resolved
<body bgcolor="white"><bean:cookie name="" id=""/>
But when I remove this tag, the Welcome.jsp works just fine.
The JSP includes other tags like :
<bean:message key="welcome.heading"/>
Those tags are working just fine.
And to finish, the ActionServlet of Struts is also working and starting with the app.
I'm guessing that there must be a classloading problem but I don't understand why the Struts ActionServlet is working : javax.servlet.http.Cookie and javax.servlet.http.HttpServlet are declared in the same package.
Maybe, there is a problem with the Oracle implementation of the Cookie class in WebLogic but it is very unlikely.
Thanks.
javax.servlet.http.Cookie is an interface showing the structure that those who are implementing the Servlet API need to implement.
The issue might be with your WebLogic 11gR1 configuration/libary: I'll explain using Tomcat 7.0.
In Tomcat 7.0, under TOMCAT_HOME/lib folder, there's a servlet-api.jar. That jar allows Tomcat to support the Java Servlet API specification (and has Cookie.class included in the directory, under javax/servlet/Cookie).
Your WebLogic 11gR1 must have a Servlet Container library that conforms to the Servlet API (like Tomcat's servlet-api.jar). I never used WebLogic, but if you have a lib folder somewhere (apparently WL_HOME/server/lib), make sure there's a servlet api somewhere (I think weblogic.jar contains servlet api implementations).
Also, please check that you don't have a servlet like library (e.g. servlet-api.jar, eclipse servlet jars, etc.) inside your WAR file as it can conflict with WebLogic's servlet library.
I've been struggling with Jetty 7 and its support for JSP and JSTL.
My JSP file:
<%# page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<%#taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<head>
<title>blah</title>
</head>
<body>
<table id="data">
<tr class="columns">
<td>Hour</td>
<c:forEach var="campaign" items="${campaigns}">
<td>${campaign}</td>
</c:forEach>
</tr>
<c:forEach var="hour" items="${results}">
<tr>
<td class="hour">${hour.key}</td>
<c:forEach var="campaign" items="${campaigns}">
<td>${hour[campaign]}</td>
</c:forEach>
</tr>
</c:forEach>
</table>
</body>
</html>
The JSP portions above work as expected. JSTL, however, does not. The campaigns and results variables are request attributes set by a servlet.
I get the following errors:
WARN: ... compiler.TagLibraryInfoImpl: Unknown element (deferred-value) in attribute
WARN: ... compiler.TagLibraryInfoImpl: Unknown element (deferred-value) in attribute
WARN: ... compiler.TagLibraryInfoImpl: Unknown element (deferred-value) in attribute
ERROR: ... javax.servlet.ServletException: java.lang.AbstractMethodError: javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext;
I am not bundling any jar files into my .war file deployed to jetty.
The version of jetty I'm using is: jetty-hightide-7.0.1.v20091125
The classpath:
/usr/local/jetty/lib/jetty-xml-7.0.1.v20091125.jar:/usr/local/jetty/lib/servlet-api-2.5.jar:/usr/local/jetty/lib/jetty-http-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-continuation-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-server-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-security-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-servlet-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-webapp-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-deploy-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-servlets-7.0.1.v20091125.jar:/usr/local/jetty/lib/jsp/ant-1.6.5.jar:/usr/local/jetty/lib/jsp/core-3.1.1.jar:/usr/local/jetty/lib/jsp/jetty-jsp-2.1-7.0.1.v20091125.jar:/usr/local/jetty/lib/jsp/jsp-2.1-glassfish-9.1.1.B60.25.p2.jar:/usr/local/jetty/lib/jsp/jsp-api-2.1-glassfish-9.1.1.B60.25.p2.jar:/usr/local/jetty/resources:/usr/local/jetty/lib/jetty-util-7.0.1.v20091125.jar:/usr/local/jetty/lib/jetty-io-7.0.1.v20091125.jar
Any help would be greatly appreciated.
Thanks in advance,
Lior.
With Jetty 8, the situation is a bit different, in case this helps anyone.
For JSTL 1.2, rather surprisingly, the taglib has to be:
<%# taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
with JSTL 1.2 from (mavenishly):
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>jstl</artifactId>
<version>1.2</version>
</dependency>
I can't really explain why the URL lacks 'jsp', but it works this way.
tsk... I don;t have privilege to comment. I am using Jetty 7.1.6 and answer provided by bmargulies works.
Basically, changing URI from
<%# taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
to
<%# taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
makes taglibs to work in Jetty 7.
-Nishant
The reason why http://java.sun.com/jsp/jstl/core doesn't work is because the code in the Jasper Jsp parser used by Jetty (org.apache.jasper.glassfish:jar:2.2.2.xxx) assumes that that uri is a systemuri (see TldScanner.java) and it will not put any taglibs with this uri in its tablib location cache. I don't know why this assumption is in the code but it is. Seems to be a bug to me.
java.lang.AbstractMethodError: javax.servlet.jsp.PageContext.getELContext()Ljavax/el/ELContext;
This exception basically means that the mentioned method cannot be found in the runtime classpath, while it was available in the compiletime classpath of either the class or one of its dependencies.
This method is introduced in JSP 2.1 which gets hand in hand with Servlet 2.5. Since Jetty 7 is supposed to support Servlet 2.5 and thus isn't the suspect here, the only cause can be that the web.xml is declared as Servlet 2.4 or lower instead of Servlet 2.5. So, to fix this particular problem, you need to declare your web.xml as at least Servlet 2.5. The <web-app> tag should look like this:
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
id="YourWebAppID"
version="2.5">
If that doesn't solve the problem, then the other cause is that the /WEB-INF/lib or even worse the /JRE/lib or /JRE/lib/ext is cluttered with appserver-specific libraries containing an older Servlet API version. E.g. servlet-api.jar from Tomcat or j2ee.jar or javaee.jar from Glassfish, etcetera. You'll need to clean up those classpath folders from any libraries which doesn't belong there, because they get precedence in classloading and will override the appserver's own libraries. Appserver-specific libraries belongs to the appserver in question, not to the webapp or JRE.
That said and apart from the actual problem, the #page attributes language="java" contentType="text/html; charset=utf-8" are all superfluous. The language already defaults to Java and the contentType already defaults to text/html and the charset will already be set to UTF-8 if you set pageEncoding="UTF-8". So the following is already sufficient:
<%#page pageEncoding="UTF-8" %>
Thx for the tip Steve! The bug seems still there, here's a workaround to run at Jetty initialisation. It did the trick for me.
import org.apache.jasper.runtime.TldScanner;
import java.util.Set;
Field field = TldScanner.class.getDeclaredField("systemUris");
field.setAccessible(true);
((Set<?>)field.get(null)).clear();
field.setAccessible(false);