Getting HTTP 500 when running servlet in Jetty
Solution 1
I would start with comparing the ear
/ war
file created before and after you changed your pom.xml
. This should lead you to jar files that were changed. Assumming everything is open source, download sources from maven repo and compare them. \
Edit: JRegex is a java library with Perl regexp support. Perhaps changing maven repo caused downloading other versions of your dependencies, and they have some optional dependency to JRegex. (You should be able to check that).
Try adding JRegex to your dependencies and see what happens. (Note this whould be a workaround if you're in production and in a hurry)
Solution 2
Jason here is what works for me, this is what I use quite often, pom.xml (relevant part) :
<dependencies>
<!-- Jetty dependencies -->
<dependency>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-embedded</artifactId>
<version>6.1.26</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>7.0.2.v20100331</version>
<configuration>
<webAppConfig>
<contextPath>/jetty-example</contextPath>
<descriptor>${basedir}/src/main/webapp/WEB-INF/web.xml</descriptor>
</webAppConfig>
<scanIntervalSeconds>5</scanIntervalSeconds>
<stopPort>9966</stopPort>
<stopKey>foo</stopKey>
<connectors>
<connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
<port>9080</port>
<maxIdleTime>60000</maxIdleTime>
</connector>
</connectors>
</configuration>
</plugin>
</plugins>
</build>
Here is the web.xml located at the location specified above in webappconfig as descriptor :
<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/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<display-name>HelloWorld Application</display-name>
<description>
lalala
</description>
<servlet>
<servlet-name>HelloServlet</servlet-name>
<servlet-class>com.mypackage.jetty.Hello</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>HelloServlet</servlet-name>
<url-pattern>/hello</url-pattern>
</servlet-mapping>
</web-app>
And the servlet itself :
public final class Hello extends HttpServlet {
private static final long serialVersionUID = 903359962771189189L;
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
response.setContentType("text/html");
PrintWriter writer = response.getWriter();
writer.println("<html>");
writer.println("<head>");
writer.println("<title>Sample Application Servlet Page</title>");
writer.println("</head>");
writer.println("<body bgcolor=white>");
writer.println("<table border=\"0\" cellpadding=\"10\">");
writer.println("<tr>");
writer.println("<td>");
writer.println("</td>");
writer.println("<td>");
writer.println("<h1>W00w I totally work</h1>");
writer.println("</td>");
writer.println("</tr>");
writer.println("</table>");
writer.println("</body>");
writer.println("</html>");
}
}
You can run the server by running mvn jetty:run
and check it at http://localhost:9080/jetty-example/hello
Additionally you can add execution to the plugin part and start the jetty when you finnish building your project. Without having to manually mvn jetty:run
every time.
<executions>
<execution> <id>start-jetty</id> <phase>pre-integration-test</phase> <goals> <goal>run</goal> </goals> <configuration> <daemon>true</daemon> </configuration> </execution> <execution> <id>stop-jetty</id> <phase>post-integration-test</phase> <goals> <goal>stop</goal> </goals> </execution>
</executions>
You can additionally add the jetty configuration file, which I use for database(for different environments). You would add the file location in the webAppConfig
of your jetty plugin like this :
<webAppConfig>
<contextPath>/my-tool</contextPath>
<descriptor>${basedir}/src/main/webapp/WEB-INF/jetty/web.xml </descriptor>
<jettyEnvXml>${basedir}/src/main/webapp/WEB-INF/jetty/jetty-env.xml </jettyEnvXml>
</webAppConfig>
And sample content of the jetty-env.xml :
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd"[]>
<Configure id="wac" class="org.eclipse.jetty.webapp.WebAppContext">
<!-- PRIMARY DATABASE -->
<New id="devDS" class="org.eclipse.jetty.plus.jndi.Resource">
<Arg>primaryDS</Arg>
<Arg>
<!-- i.e. Postgress -->
<New class="org.postgresql.ds.PGSimpleDataSource">
<Set name="User">myuser</Set>
<Set name="Password">password</Set>
<Set name="DatabaseName">database</Set>
<Set name="ServerName">database.stackoverflow.com</Set>
<Set name="PortNumber">5432</Set>
</New>
</Arg>
</New>
<!-- BACKUP DATABASE
<New id="devDS" class="org.eclipse.jetty.plus.jndi.Resource">
<Arg>backupDS</Arg>
<Arg>
.....
</Arg>
-->
</Configure>
You should be good with this.
Jason Axelson
Software developer in Hawaii. Specializes in Elixir and Ruby on Rails.
Updated on June 04, 2022Comments
-
Jason Axelson almost 2 years
I have a servlet that was running fine until a few days ago. But the only thing that I've changed is the nexus repo I'm using for maven. I'm running the servlet via mvn jetty:run
But when I try to access the site instead of seeing the home page, I see:
HTTP ERROR 500 Problem accessing /. Reason: jregex/Pattern
I can access other url's fine such as /favicon.ico. But I can't find anything on this jregex/Pattern error and it doesn't look like the jregex library is being used in the code at all.
I also don't see any problems in the logs. It looks like requests for the homepage are not making it to my servlet but requests for other pages are.
This is happening on both Arch Linux and Mac OS X 10.7
This is almost certainly a dependency issue because after replacing my
~/.m2
folder with an old one (with dependencies from the old nexus server) it works.Sometimes I also get:
HTTP ERROR: 503 Problem accessing /. Reason: SERVICE_UNAVAILABLE
-
Jason Axelson almost 12 yearsThanks! I am 90% sure I have it solved now. Comparing the two versions of the war's led me to notice that different versions of uasparser were being used. The good version used 2012-02-08 while the bad version used 2012-05-09. This change was made by someone else and I didn't look into it enough because I didn't realize this was an application-level failure and not jetty-level.
-
Jason Axelson almost 12 yearsThanks for the detailed explanation but it turns out that this was actually an application level problem and not jetty-level.