¿Cómo configuro correctamente el UrlrewriteFilter de Tuckey?

Question

Por lo tanto, espero que UrlReWriteFilter de UrlRite del usuario para redirigir a los usuarios que intenten acceder a versiones anteriores de un producto de servicio web. Cosas simples como la redirección www.blah.com/oldversion/blah/blah a www.blah.com/newversion/blah/blah

He pasado un poco de tiempo tratando de configurar correctamente esto de acuerdo con las instrucciones algo vagas sobre Tuckey's sitio web Pero estoy teniendo algunas dificultades.

Tengo los archivos en las ubicaciones correctas. UrlReWrite.xml se encuentra en la carpeta Web-INF del paquete WebApp, adyacente a web.xml. UrlReWrite-3.2.0.Jar está en la carpeta LIB de Web-INF.

Aquí está mi web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="http://java.sun.com/xml/ns/javaee" 
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">

<filter>
   <filter-name>UrlRewriteFilter</filter-name>
   <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>
<filter-mapping>
   <filter-name>UrlRewriteFilter</filter-name>
   <url-pattern>/*</url-pattern>
   <dispatcher>REQUEST</dispatcher>
   <dispatcher>FORWARD</dispatcher>
</filter-mapping>
<filter>
    <filter-name>Jersey Web Application</filter-name>
    <filter-class>com.sun.jersey.spi.container.servlet.ServletContainer</filter-class>
    <init-param>
        <param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
        <param-value>com.sun.jersey.api.container.filter.LoggingFilter</param-value>
    </init-param>
    <!--
    <init-param>
        <param-name>com.sun.jersey.spi.container.ContainerResponseFilters</param-name>
        <param-value>com.sun.jersey.api.container.filter.LoggingFilter</param-value>
    </init-param>
    -->
    <init-param>
        <param-name>com.sun.jersey.spi.container.ContainerRequestFilters</param-name>
        <param-value>project's.security.filter</param-value>
    </init-param>
    <init-param>
        <param-name>com.sun.jersey.config.property.packages</param-name>
        <param-value>project's.base.package</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>Jersey Web Application</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

<ejb-local-ref>
    REFERENCED EJB
</ejb-local-ref>

<ejb-local-ref>
    REFERENCED EJB
</ejb-local-ref>
</web-app>

Aquí está mi urlrewrite.xml:

<?xml version="1.0" encoding="utf-8"?>
<!--
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
    "http://tuckey.org/res/dtds/urlrewrite3.2.dtd">-->


<!--

Configuration file for UrlRewriteFilter
http://tuckey.org/urlrewrite/

-->
<urlrewrite>

<rule>
    <from>^/2.0/rest/$</from>
    <to type="redirect">/3.2-SNAPSHOT/rest/$1</to>
</rule>
<rule>
    <note>
        The rule means that requests to /test/status/ will be redirected to /rewrite-status
        the url will be rewritten.
    </note>
    <from>/test/status/</from>
    <to type="redirect">%{context-path}/rewrite-status</to>
</rule>


<outbound-rule>
    <note>
        The outbound-rule specifies that when response.encodeURL is called (if you are using JSTL c:url)
        the url /rewrite-status will be rewritten to /test/status/.

        The above rule and this outbound-rule means that end users should never see the
        url /rewrite-status only /test/status/ both in thier location bar and in hyperlinks
        in your pages.
    </note>
    <from>/rewrite-status</from>
    <to>/test/status/</to>
</outbound-rule>

</urlrewrite>

Cuando construyo e implemento el proyecto, estas líneas relacionadas con UrlReWriteFilter se imprimen en el registro del servidor:

[#|2011-12-06T10:28:56.924-0500|INFO|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=24;_ThreadName=Thread-2;|PWC1412: WebModule[null] ServletContext.log():org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: destroy called|#]
...
[#|2011-12-06T10:29:04.069-0500|INFO|glassfish3.1.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=24;_ThreadName=Thread-2;|PWC1412: WebModule[null] ServletContext.log():org.tuckey.web.filters.urlrewrite.UrlRewriteFilter INFO: loaded (conf ok)|#]

Cuando intento acceder a una URL en 2.0, debería redirigirme a 3.2-snapshot. En cambio, recibo un error 404. Nada aparece en el servidor.log, y en mis registros de error Java veo que el paquete UrlrewriteFilter nunca se toca. Así que creo que debe haber algo incorrecto en mi configuración.

Avíseme si necesita más información y gracias por su tiempo y ayuda.

Answer 1

El problema terminó relacionado con el pom.xml de mi paquete de oído. En eso, la raíz de contexto de la aplicación se estableció para incluir la pieza del URI que intentaba cambiar. Debido a que solo se accedería a la aplicación cuando la raíz de contexto se igualara, Tuckey, por supuesto, no podría utilizarse.

Ej: El usuario ingresa a la URL www.blank.com/2.0/etc y quería redirigir a www.blank.com/3.0/etc

fragmento de pomcho de oreja incorrecto:

<webModule>
    <groupId>com.etc</groupId>
    <artifactId>webservice-rest-webapp</artifactId>
    <contextRoot>/3.0/</contextRoot>
</webModule>

Fragmento correcto de la oreja de la oreja:

<webModule>
    <groupId>com.etc</groupId>
    <artifactId>webservice-rest-webapp</artifactId>
    <contextRoot>/</contextRoot>
</webModule>

Debido a que ya no tengo esa raíz de contexto especificada, por supuesto tengo que modificar los parámetros de ruta para mis diversos URI a lo largo del programa para incluir el número de versión.