Сервлет для обслуживания статического контента

У меня была та же проблема, и я решил ее при помощи кода 'сервлета по умолчанию' от кодовой базы Tomcat.

http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/servlets/DefaultServlet.java

DefaultServlet является сервлетом, который служит статическим ресурсам (jpg, HTML, css, gif и т.д.) в Tomcat.

Этот сервлет очень эффективен и имеет некоторых свойства, которые Вы определили выше.

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

• Ссылки на org.apache.naming.resources пакет могут быть удалены или заменены java.io. Код файла.
• Ссылки на org.apache.catalina.util пакет являются propably только служебными методами/классами, которые могут быть дублированы в Вашем исходном коде.
• Ссылки на org.apache.catalina. Класс Globals может быть встроен или удален.

Используйте org.mortbay.jetty.handler. ContextHandler. Вам не нужны дополнительные компоненты как StaticServlet.

В причале домой,

контексты CD $

CP $ javadoc.xml static.xml

$ vi static.xml

...

<Configure class="org.mortbay.jetty.handler.ContextHandler">
<Set name="contextPath">/static</Set>
<Set name="resourceBase"><SystemProperty name="jetty.home" default="."/>/static/</Set>
<Set name="handler">
  <New class="org.mortbay.jetty.handler.ResourceHandler">
    <Set name="cacheControl">max-age=3600,public</Set>
  </New>
 </Set>
</Configure>

Установленный значение contextPath с Вашим префиксом URL, и установленный значение resourceBase как путь к файлу статического содержания.

Это работало на меня.

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

package com.example;

import java.io.*;

import javax.servlet.*;
import javax.servlet.http.*;

public class DefaultWrapperServlet extends HttpServlet
{   
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException
    {
        RequestDispatcher rd = getServletContext().getNamedDispatcher("default");

        HttpServletRequest wrapped = new HttpServletRequestWrapper(req) {
            public String getServletPath() { return ""; }
        };

        rd.forward(wrapped, resp);
    }
}

См. StaticFile в JSOS: http://www.servletsuite.com/servlets/staticfile.htm

Я нашел в Интернете отличное руководство по обходному пути. Это просто и эффективно, я использовал его в нескольких проектах с подходом стилей URL-адресов REST:

http://www.kuligowski.pl/java/rest-style-urls-and-url-mapping-for-static-content -apache-tomcat, 5

Чтобы обслуживать все запросы от приложения Spring, а также /favicon.ico и файлы JSP из / WEB-INF / jsp / *, которые Spring's AbstractUrlBasedView запросит, вы можете просто переназначить сервлет jsp и сервлет по умолчанию:

  <servlet>
    <servlet-name>springapp</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>jsp</servlet-name>
    <url-pattern>/WEB-INF/jsp/*</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>/favicon.ico</url-pattern>
  </servlet-mapping>

  <servlet-mapping>
    <servlet-name>springapp</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>

Мы не можем полагаться на шаблон URL-адреса * .jsp в стандартном сопоставлении для сервлета jsp, потому что шаблон пути '/ *' сопоставляется до проверки любого сопоставления расширения. Сопоставление сервлета jsp с более глубокой папкой означает, что он соответствует первым. Соответствие '/favicon.ico' происходит точно до сопоставления с шаблоном пути. Более глубокие совпадения пути или точные совпадения будут работать, но никакие совпадения расширений не могут пройти мимо совпадения пути '/ *'. Отображение '/' на сервлет по умолчанию не работает. Можно подумать, что точный '/' превзойдет шаблон пути '/ *' в springapp.

Вышеупомянутый фильтр не работает для перенаправленных / включенных JSP-запросов из приложения. Чтобы заставить его работать, мне пришлось применить фильтр напрямую к springapp, после чего сопоставление URL-шаблона было бесполезным, поскольку все запросы, которые поступают в приложение, также попадают в его фильтры. Итак, я добавил сопоставление с образцом в фильтр, а затем узнал о сервлете jsp и увидел, что он не удаляет префикс пути, как это делает сервлет по умолчанию. Это решило мою проблему, которая была не совсем такой же, но достаточно распространенной.

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

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

У меня были хорошие результаты с FileServlet , так как он поддерживает почти все HTTP (etags, фрагменты и т. Д.).

Я сделал это, расширив tomcat DefaultServlet ( src ) и переопределив метод getRelativePath ().

package com.example;

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import org.apache.catalina.servlets.DefaultServlet;

public class StaticServlet extends DefaultServlet
{
   protected String pathPrefix = "/static";

   public void init(ServletConfig config) throws ServletException
   {
      super.init(config);

      if (config.getInitParameter("pathPrefix") != null)
      {
         pathPrefix = config.getInitParameter("pathPrefix");
      }
   }

   protected String getRelativePath(HttpServletRequest req)
   {
      return pathPrefix + super.getRelativePath(req);
   }
}

... И вот мои сопоставления сервлетов

<servlet>
    <servlet-name>StaticServlet</servlet-name>
    <servlet-class>com.example.StaticServlet</servlet-class>
    <init-param>
        <param-name>pathPrefix</param-name>
        <param-value>/static</param-value>
    </init-param>       
</servlet>

<servlet-mapping>
    <servlet-name>StaticServlet</servlet-name>
    <url-pattern>/static/*</url-pattern>
</servlet-mapping>  

Я придумал немного другое решение. Это немного хакерски, но вот сопоставление:

<servlet-mapping>   
    <servlet-name>default</servlet-name>
    <url-pattern>*.html</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>*.jpg</url-pattern>
</servlet-mapping>
<servlet-mapping>
 <servlet-name>default</servlet-name>
    <url-pattern>*.png</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>*.css</url-pattern>
</servlet-mapping>
<servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>*.js</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>myAppServlet</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

Это в основном просто сопоставляет все файлы содержимого по расширению с сервлетом по умолчанию, а все остальное с «myAppServlet».

Это работает как в Jetty, так и в Tomcat.