How do you get embedded Jetty 9 to successfully resolve the JSTL URI?

William Proffitt picture William Proffitt · Jul 16, 2013 · Viewed 17.5k times · Source

I'm packaging a Web Application Archive (.war) so that it can be started via java -jar webapp.war in a shell by launching an embedded copy of Jetty 9 using this code in a main class:

int port = Integer.parseInt(System.getProperty("port", "80")); // I know this has implications :)
String contextPath = System.getProperty("contextPath", "");
Server server = new Server(port);
ProtectionDomain domain = Deployer.class.getProtectionDomain();
URL location = domain.getCodeSource().getLocation();
WebAppContext webapp = new WebAppContext();
webapp.setContextPath("/" + contextPath);
webapp.setWar(location.toExternalForm());
server.setHandler(webapp);
server.start();
server.join();

However, I'm running into this error when the first JSP containing a JSTL taglib declaration gets compiled:

org.apache.jasper.JasperException: /WEB-INF/html/user/login.jsp(2,62) PWC6188: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:92)
at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:378)
at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:172)
at org.apache.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:431)
at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:240)
at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:502)
at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:582)
at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1652)
at org.apache.jasper.compiler.Parser.parse(Parser.java:185)
at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:244)
at org.apache.jasper.compiler.ParserController.parse(ParserController.java:145)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:212)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:451)
at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:625)
at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:374)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:698)
etc...

The first couple lines of that JSP are as follows:

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1" isELIgnored="false" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

I've looked around quite a bit (this doesn't seem to be a new issue) and have tried the following solutions:

  • Slimming down my dependencies and looking for conflicts (currently I'm only depending on jetty-server, jetty-webapp, and jetty-jsp, all version 9.0.4.v20130625)
  • Specifying an explicit <taglib> mapping in the webapp's web.xml file that points to JSTL directly (got this idea from reading the JSP spec)
  • Modifying the server classpath as per this answer
  • Taking advantage of methods of WebAppContext such as addServerClass and setParentLoaderPriority

According to Jetty's documentation, using JSTL should just work, but I think the embedded context may be changing the way JSTL gets loaded and causing it to fail.

Would appreciate any ideas or suggestions. This setup would be replacing an older setup that did the same thing successfully on Windows but was not functioning on Linux due to the inclusion of an old dependency that brought in this bug. Unfortunately, I haven't been able to find a quick replacement for that dependency (groupId org.mortbay.jetty artifactId jsp-2.1-glassfish version 2.1.v20100127) that doesn't introduce the JSTL URI stack trace mentioned above.

UPDATE: I've found a suboptimal solution. A downgrade to Jetty 7 inspired by this thread now has me up and running. This is great news, but it's discouraging that if I later required any functionality exclusive to Jetty 8 or Jetty 9 that I'd have to scrap this deployment infrastructure. Any insight on JSTL taglib issue in Jetty 9 would still be appreciated.

Answer

Jan Zyka picture Jan Zyka · Nov 21, 2013

So here is yet another solution. I was struggling with very similar problem only I have a separate war file and a simple embedder class which creates a Jetty server for me and starts it up pointing to possibly any war file. Here is how this all work.

  1. The war file doesn't have any tld library in WEB-INF/lib and is completely separated from the loader miniapplication.

  2. The Loader application Main class which starts the server and points it to any war file has following dependencies (maven):

        <!-- Jetty webapp -->
        <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-webapp</artifactId>
            <version>${jettyVersion}</version>
        </dependency>
    
        <!-- With JSP support -->
        <dependency>
            <groupId>org.eclipse.jetty</groupId>
            <artifactId>jetty-jsp</artifactId>
            <version>${jettyVersion}</version>
        </dependency>
    

  3. The loading class itself looks as:

    Server server = new Server(cncPort);
    
    WebAppContext webApp = new WebAppContext();
    
    webApp.setContextPath(applicationContext);
    webApp.setWar(jettyHome + "/" + warFile);
    server.setHandler(webApp);
    
    try {
        server.start();
        server.join();
    } catch (Exception ex) {
        System.out.println("Failed to start server.");
        ex.printStackTrace();
    } 
    
  4. The resulting package in my case looks as follows:

    + EmbedderApp
    |
    +-- lib
      - EmbeddedApp.jar <-- JAR with the embedder class
      - com.sun.el-2.2.0.v201303151357.jar
      - javax.el-2.2.0.v201303151357.jar
      - javax.servlet-3.0.0.v201112011016.jar
      - javax.servlet.jsp-2.2.0.v201112011158.jar
      - javax.servlet.jsp.jstl-1.2.0.v201105211821.jar
      - jetty-http-9.0.6.v20130930.jar
      - jetty-io-9.0.6.v20130930.jar
      - jetty-jsp-9.0.6.v20130930.jar
      - jetty-security-9.0.6.v20130930.jar
      - jetty-server-9.0.6.v20130930.jar
      - jetty-servlet-9.0.6.v20130930.jar
      - jetty-util-9.0.6.v20130930.jar
      - jetty-webapp-9.0.6.v20130930.jar
      - jetty-xml-9.0.6.v20130930.jar
      - org.apache.jasper.glassfish-2.2.2.v201112011158.jar
      - org.apache.taglibs.standard.glassfish-1.2.0.v201112081803.jar
      - org.eclipse.jdt.core-3.8.2.v20130121.jar
    
  5. My dependecies were simply added via assembly plugin as

    <dependencySet>
        <outputDirectory>lib</outputDirectory>
        <scope>runtime</scope>
    </dependencySet>
    
  6. I have a shell start script launching the embedding class and here comes what took me ages to figure out.

    I used a manifest with classpath embedded within the jar and setting my CLASSPATH=<PATH_TO_APP>\lib\EmbeddedApp.jar assuming the reset of the dependencies are part of my classpath through the manifest. And I was gettign the same unresolvable URI error.

    Once I added changed the CLASSPATH variable within my script to contain all the jars explicitely it started to work.

    for jar in ${APP_ROOT}/lib/*.jar; do CLASSPATH=$jar:${CLASSPATH}; done 
    

Hope this can save someones time :-)