Pakuję archiwum aplikacji WWW (.war), aby można było uruchomić za pośrednictwemjava -jar webapp.war w powłoce, uruchamiając osadzoną kopię Jetty 9, używając tego kodu w głównej klasie:

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();

Jednak ten błąd pojawia się, gdy kompilowana jest pierwsza strona JSP zawierająca deklarację JSTL taglib:

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...

Pierwsze kilka wierszy tego JSP wygląda następująco:

<%@ 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" %>

Rozglądałem się trochę (to nie wydaje się być nowym problemem) i wypróbowałem następujące rozwiązania:

Odchudzanie moich zależności i szukanie konfliktów (obecnie zależę tylko odjetty-server, jetty-webapp, ijetty-jsp, cała wersja9.0.4.v20130625)Określanie jawne<taglib> mapowanie w pliku web.xml webappa, który wskazuje bezpośrednio JSTL (ten pomysł nie został odczytany ze specyfikacji JSP)Modyfikowanie ścieżki klasy serwera zgodnie zta odpowiedźWykorzystanie metod WebAppContext, takich jakaddServerClass isetParentLoaderPriority

WedługDokumentacja Jetty, używanie JSTL powinno po prostu działać, ale myślę, że osadzony kontekst może zmieniać sposób ładowania JSTL i powodowania niepowodzenia.

Będzie wdzięczny za wszelkie pomysły lub sugestie. Ta konfiguracja zastąpiłaby starszą konfigurację, która pomyślnie wykonała to samo w systemie Windows, ale nie działała na Linuksie z powodu włączenia starej zależności, która wprowadziłaten błąd. Niestety, nie udało mi się znaleźć szybkiego zamiennika tej zależności (groupIdorg.mortbay.jetty artefaktjsp-2.1-glassfish wersja2.1.v20100127), który nie wprowadza wspomnianego powyżej śladu stosu URI JSTL.

AKTUALIZACJA: Znalazłem suboptymalne rozwiązanie. Przejście na Jetty 7 inspirowane przezten wątek teraz ma mnie uruchomionego. To świetna wiadomość, ale zniechęca to, że gdybym później potrzebował jakiejkolwiek funkcjonalności wyłącznie dla Jetty 8 lub Jetty 9, musiałbym zlikwidować tę infrastrukturę wdrożeniową. Jakikolwiek wgląd w problem taglib JSTL w Jetty 9 będzie nadal doceniany.