Как получить встроенный Jetty 9 для успешного разрешения URI JSTL?

Ответ 1

К сожалению, ни один из ответов до сих пор не работал у меня. Но я наконец нашел решение моей проблемы. Это будет звучать как взломать, и это определенно похоже на одно.

Но если я создам все, как описано в моем вопросе, вплоть до того момента, когда JSTL не будет разрешаться, я могу сделать один шаг, который заставит все работать, почти как магия.

Этот шаг создания сжимания изменяет расширение в файле .war на .jar. Как только я это сделаю, JSTL отлично справляется, и все работает.

Итак, сейчас я создаю .war, который можно вставить в контейнер сервлета, или вы можете переименовать его в .jar и запустить автономный. И он работает как в Unix, так и в Windows, тогда как то, как я делал это раньше, не будет работать в Unix из-за ошибки, присутствующей в библиотеке jsp-2.1-glassfish, упомянутой Джеймсом Куком.

Соответствующие бит из моего pom:

<properties>
    <jetty.version>9.0.5.v20130815</jetty.version>
    <war.class>com.domain.package.DeployWebapp</war.class>
    <war.class.path>com/domain/package</war.class.path>
</properties>    

<dependency>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-server</artifactId>
    <version>${jetty.version}</version>
    <scope>provided</scope>
</dependency>

<dependency>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-webapp</artifactId>
    <version>${jetty.version}</version>
    <scope>provided</scope>
</dependency>

<dependency>
    <groupId>org.eclipse.jetty</groupId>
    <artifactId>jetty-jsp</artifactId>
    <version>${jetty.version}</version>
    <scope>provided</scope>
</dependency>

<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.7</version>
    <executions>
        <execution>
            <id>main-class-placement</id>
            <phase>prepare-package</phase>
            <configuration>
                <tasks>
                    <move todir="${project.build.directory}/${project.artifactId}-${project.version}/${war.class.path}">
                    <fileset dir="${project.build.directory}/classes/${war.class.path}">
                        <include name="DeployWebapp.class" />
                    </fileset>
                </move>
                        </tasks>
                </configuration>
                <goals>
                    <goal>run</goal>
                </goals>
            </execution>
    </executions>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <version>2.3</version>
    <executions>
        <execution>
            <id>jetty-classpath</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>unpack-dependencies</goal>
            </goals>
            <configuration>
                <includeGroupIds>org.eclipse.jetty,javax.servlet,javax.el,org.glassfish.web,org.eclipse.jetty.orbit,org.ow2.asm,javax.annotation</includeGroupIds>
                <outputDirectory>
                    ${project.build.directory}/${project.artifactId}-${project.version}
                </outputDirectory>
            </configuration>
        </execution>
    </executions>
</plugin>

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <version>2.4</version>
    <configuration>
        <attachClasses>true</attachClasses>
        <archiveClasses>true</archiveClasses>
        <archive>
            <manifest>
                <mainClass>${war.class}</mainClass>
            </manifest>
        </archive>
        <packagingExcludes>META-INF/*.SF</packagingExcludes>
        <packagingExcludes>META-INF/*.DSA</packagingExcludes>
        <packagingExcludes>META-INF/*.RSA</packagingExcludes>
    </configuration>
</plugin>

Ответ 2

Итак, вот еще одно решение. Я боролся с очень схожей проблемой, только у меня есть отдельный файл войны и простой класс для внедрения, который создает для меня сервер Jetty и запускает его, указывая на возможный файл войны. Вот как все это работает.

• Файл войны не имеет библиотеки tld в WEB-INF/lib и полностью отделен от мини-приложения загрузчика.

• Приложение Loader Основной класс, который запускает сервер и указывает его на любой файл войны, имеет следующие зависимости (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>
  

• Класс загрузки выглядит следующим образом:

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

• Полученный пакет в моем случае выглядит следующим образом:

  + 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
  

• Мои зависимости были просто добавлены через плагин сборки как

  <dependencySet>
      <outputDirectory>lib</outputDirectory>
      <scope>runtime</scope>
  </dependencySet>
  

• У меня есть запуск оболочки script, запускающий класс внедрения, и вот что взяло меня на себя, чтобы понять.

  Я использовал манифест с classpath, встроенный в jar, и установил мой CLASSPATH=<PATH_TO_APP>\lib\EmbeddedApp.jar, предполагая, что reset зависимостей являются частью моего пути к классам через манифест. И я получил то же самое неразрешимое Ошибка URI.

  Как только я добавил измененную переменную CLASSPATH в моем script, чтобы содержать все банки явно, она начала работать.

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

Надеюсь, это может сэкономить время: -)

Ответ 3

У меня была та же проблема, что и запуск Jetty из теста Surefire; проблема в том, что Jetty 9 не смотрит на манифесты любых файлов jar, кроме WEB-INF, что несовместимо с тем, как я писал свои тесты.

Чтобы обойти эту проблему, я написал немного кода, чтобы найти файлы jar из манифеста и поместить их в новый промежуточный URLClassLoader.

Это то, что моя функциональная функция тестирования теста оказалась похожей на работу с Jetty 9:

@Before @SuppressWarnings("unchecked")
public void setUp() throws Exception {

    WebAppContext ctx = new WebAppContext("src/main/webapp", "/");

    Server server = new Server(9000);

    ctx.setServer(server);
    server.setHandler(ctx);

    ctx.preConfigure();

    ctx.addOverrideDescriptor("src/main/webapp/WEB-INF/tests-web.xml");      

    // Replace classloader with a new classloader with all URLs in manifests 
    // from the parent loader bubbled up so Jasper looks at them.
    ClassLoader contextClassLoader = ctx.getClassLoader();
    ClassLoader parentLoader = contextClassLoader.getParent();
    if (contextClassLoader instanceof WebAppClassLoader &&
        parentLoader instanceof URLClassLoader) {
      LinkedList<URL> allURLs =
          new LinkedList<URL>(Arrays.asList(((URLClassLoader)parentLoader).getURLs()));
      for (URL url : ((LinkedList<URL>)allURLs.clone())) {
        try {
          URLConnection conn = new URL("jar:" + url.toString() + "!/").openConnection();
          if (!(conn instanceof JarURLConnection))
            continue;
          JarURLConnection jconn = (JarURLConnection)conn;
          Manifest jarManifest = jconn.getManifest();
          String[] classPath = ((String)jarManifest.getMainAttributes().getValue("Class-Path")).split(" ");

          for (String cpurl : classPath)
            allURLs.add(new URL(url, cpurl));
        } catch (IOException e) {} catch (NullPointerException e) {}
      }

      ctx.setClassLoader(
          new WebAppClassLoader(
              new URLClassLoader(allURLs.toArray(new URL[]{}), parentLoader),
              ((WebAppClassLoader)contextClassLoader).getContext()));
    }

    server.start();
}

Мой образец кода помещается в общедоступный домен - вы можете использовать его в своем собственном коде (атрибуция оценивается, но не требуется).

Ответ 4

После прокрутки с помощью решения a1kmm и заканчивая NullPointers, я заметил, что я не устанавливал Classloader в WebAppContext. Используя следующую строку, я больше не нуждаюсь в настраиваемой настройке сканирования загрузки/манифеста.

webAppContext.setClassLoader(new WebAppClassLoader(getClass().getClassLoader(), webAppContext));

Ответ 5

У меня была эта точная проблема. И я решил это самым необычным способом.

Я использую Maven как инструмент сборки, но вот как я создавал свою независимую версию WAR.

<profile>
        <id>Jetty_9</id>
        <properties>
            <jetty9.version>9.0.4.v20130625</jetty9.version>
        </properties>
        <dependencies>
            <dependency>
                <groupId>ch.qos.logback</groupId>
                <artifactId>logback-classic</artifactId>
                <version>${logback.version}</version>
                <scope>provided</scope>
            </dependency>
            <dependency>
                <groupId>ch.qos.logback</groupId>
                <artifactId>logback-access</artifactId>
                <version>${logback.version}</version>
                <scope>provided</scope>
            </dependency>
            <dependency>
                <groupId>ch.qos.logback</groupId>
                <artifactId>logback-core</artifactId>
                <version>${logback.version}</version>
                <scope>provided</scope>
            </dependency>
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-api</artifactId>
                <version>${slf4j.version}</version>
                <scope>provided</scope>
            </dependency>

            <dependency>
                <groupId>org.eclipse.jetty.orbit</groupId>
                <artifactId>javax.servlet</artifactId>
                <version>3.0.0.v201112011016</version>
                <scope>provided</scope>
            </dependency>
            <dependency>
                <groupId>org.eclipse.jetty</groupId>
                <artifactId>jetty-webapp</artifactId>
                <version>${jetty9.version}</version>
                <scope>provided</scope>
            </dependency>
            <dependency>
                <groupId>org.eclipse.jetty</groupId>
                <artifactId>jetty-plus</artifactId>
                <version>${jetty9.version}</version>
                <scope>provided</scope>
            </dependency>
            <dependency>
                <groupId>org.eclipse.jetty</groupId>
                <artifactId>jetty-jsp</artifactId>
                <version>${jetty9.version}</version>
            </dependency>            
        </dependencies>
        <build>
            <plugins>
                <plugin>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>2.3.2</version>
                    <configuration>
                        <source>${compileSource}</source>
                        <target>${compileSource}</target>
                    </configuration>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-antrun-plugin</artifactId>
                    <version>1.7</version>
                    <executions>
                        <execution>
                            <id>main-class-placement</id>
                            <phase>prepare-package</phase>
                            <configuration>
                                <target>
                                    <move todir="${project.build.directory}/${project.build.finalName}/">
                                        <fileset dir="${project.build.directory}/classes/">
                                            <include name="Main.class"/>
                                        </fileset>
                                    </move>
                                </target>
                            </configuration>
                            <goals>
                                <goal>run</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-dependency-plugin</artifactId>
                    <version>2.6</version>
                    <executions>
                        <execution>
                            <id>jetty-classpath</id>
                            <phase>prepare-package</phase>
                            <goals>
                                <goal>unpack-dependencies</goal>
                            </goals>
                            <configuration>
                                <includeGroupIds>
                                    org.eclipse.jetty,org.slf4j,ch.qos
                                </includeGroupIds>                                    
                                <includeScope>provided</includeScope>
                                <excludes>META-INF/*.SF,META-INF/*.RSA,about.html, about_files/**, readme.txt,
                                    plugin.properties, jetty-dir.css
                                </excludes>
                                <outputDirectory>
                                    ${project.build.directory}/${project.build.finalName}
                                </outputDirectory>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-war-plugin</artifactId>
                    <version>2.3</version>
                    <configuration>
                        <archive>
                            <manifest>
                                <mainClass>Main</mainClass>
                            </manifest>
                        </archive>
                    </configuration>
                    <executions>
                        <execution>
                            <id>default-war</id>
                            <phase>package</phase>
                            <goals>
                                <goal>war</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
    </profile>

Но, как и я, я получал эту ошибку. После того, как после 2-го дня я был убит после смерти, я нашел это - http://internna.blogspot.co.uk/2011/08/step-by-step-executable-war-files.html

Выключив зависимость jetty-jsp для этого:

 <dependency>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>jsp-2.1-glassfish</artifactId>
            <version>2.1.v20100127</version>
 </dependency>

Все началось волшебным образом!

С этого момента я не могу объяснить, почему он работает. Но я очень хочу узнать

Ответ 6

Я только что создал простой jsp с ta taglib, когда вы используете. Затем создайте серверное приложение, и оно работает. Итак, я думаю, что это не теглиб, который вызывает проблему.

public static void main(String[] args) throws Exception {
    Server server = new Server(8680);
    HandlerCollection handlers = new HandlerCollection();
    server.setHandler(handlers);
    ContextHandlerCollection chc = new ContextHandlerCollection();
    handlers.addHandler(chc);
    WebAppContext webapp = new WebAppContext();
    webapp.getInitParams().put("org.eclipse.jetty.servlet.Default.useFileMappedBuffer",    
    "false");
    webapp.setContextPath("/WebAppMng01");
    //URL url = ManagedServer.class.getResource("/WebAppMng01/build/web");
    URL url = ManagedServer.class.getResource("/WebAppMng01/dist/WebAppMng01.war");
    if (url != null) {
        webapp.setWar(url.toExternalForm());
        chc.addHandler(webapp);
    }
    server.start();
    server.join();
}   

Ответ 7

Кажется, что встроенный jetty 9 не любит автоматически использовать любые записи пути класса из вашего основного исполняемого файла jar. Это включает библиотеки taglib. Добавление записей пути к классам непосредственно в webappclassloader тоже не работает. По какой-либо причине записи пути класса должны добавляться к родительскому элементу webappclassloader.

Простое решение для меня не работает:

    webAppContext.setClassLoader(new WebAppClassLoader(getClass().getClassLoader(), webAppContext));

Но сканирование манифеста вручную. Я переписал приведенный выше пример сканирования, чтобы увидеть, что происходит, и попробовать различные вещи, которые я буду здесь включать.

//========== create WebAppClassloader with a new parent classloader with all URLs in manifests=================== 
    //search for any secondary class path entries
    Vector<URL> secondayClassPathURLVector = new Vector<>();
    ClassLoader parentClassLoader = this.getClass().getClassLoader();
    if(parentClassLoader instanceof URLClassLoader)
    {
        URL[] existingURLs = ((URLClassLoader)parentClassLoader).getURLs(); 
        for (URL parentURL : existingURLs)
        {
            //if it doesn't end in .jar, then it probably not going to have Manifest with a Class-Path entry 
            if(parentURL.toString().endsWith(".jar"))
            {
                JarURLConnection jarURLConnection = (JarURLConnection) new URL("jar:" + parentURL.toString() + "!/").openConnection();
                Manifest jarManifest = jarURLConnection.getManifest();
                String classPath = jarManifest.getMainAttributes().getValue("Class-Path");
                if(classPath != null)
                {
                    //Iterate through all of the class path entries and create URLs out of them                                                
                    for (String part : classPath.split(" "))
                    {
                        //add our full path to the jar file to our classpath list
                        secondayClassPathURLVector.add(new URL(parentURL,part));                     
                    }
                }
            }                
        }
    }
    //use our class path entries to create a parent for the webappclassloader that knows how to use or referenced class paths
    URLClassLoader internalClassPathUrlClassLoader = new URLClassLoader(secondayClassPathURLVector.toArray(new URL[secondayClassPathURLVector.size()]), parentClassLoader);
    //create a new webapp class loader as a child of our  internalClassPathUrlClassLoader. For whatever reason Jetty needs to have a WebAppClassLoader be it main class loader,
    //while all of our classpath entries need to be added to the parent class loader   
    WebAppClassLoader webAppClassLoader = new WebAppClassLoader(internalClassPathUrlClassLoader,context);
    context.setClassLoader(webAppClassLoader);

Это должно заменить пример embedded-jetty-jsp, который просто не работает по какой-либо причине, но должен, поскольку любые записи в классе должны автоматически включаться в путь к классам. Однако он говорит, что JSP требует загрузчика классов системы NON. Поэтому я могу только предположить, что JSP прекращает сканирование пути класса, когда он достигает загрузчика Systempathpath. Вот почему мы действительно должны его заменить.

Ответ 8

WebAppContext context = new WebAppContext();      
final URL url = getClass().getProtectionDomain().getCodeSource().getLocation();
if (url != null) {
    context.getMetaData().addWebInfJar(JarResource.newResource(url));
}

Добавьте жировую банку как банку WEB-INF, пусть MetaInfConfiguration найдет *.tld файлы.

Ссылка:

• https://eclipse.googlesource.com/jetty/org.eclipse.jetty.project/+/b3be24742353f7b5880fa8229a20ed0b19058cac/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/MetaInfConfiguration.java#123
• https://github.com/wacai/json-template-renderer