title: Jersey can't find my resource when the request is wrapped by my filter. Works fine from the browser
body: <p>I'm using Tomcat (7.0.8x) and Jersey (2.25.1).
  As part of a POC, I've written a Filter to intercept some client requests and forward them, after changing the requestURI, to a Jax-RS resource.
  The incoming requests are not REST but simple POST requests, that expect JSON response.<br>
  My filter, modifies the request uri, targetting a JAX-RS resource.
  The problem is that requests that get modified by the filter result in 404 "The requested resource is not available", but if i enter the request that my filter is supposed to produce, from the browser or Postman it works fine.</p>
  
  <p>So the filter is not doing all that it should and I'm here looking for some insight.</p>
  
  <p>The initial target resource is a simple code i copied from some where:<br>
  (note that from the browser the request works with the @Produces commented or not, and it does not work with my filter, whether the @Produces is commented or not)  </p>
  
  <pre><code>package com.test;
  
  //a bunch of imports 
  @Path("/helloworld")
  public class HelloWorld {
  
      @GET //this works w/o the filter with the line below commented or uncommented but does not work 
      //@Produces(MediaType.APPLICATION_JSON)
      public String sayJsonHello() {
          return "{ \"status\": \"json\" }";
      }
  
      @POST
      //@Produces(MediaType.APPLICATION_JSON)
      @Produces(MediaType.TEXT_PLAIN)
      @Consumes(MediaType.APPLICATION_FORM_URLENCODED)
      public String sayJsonPostHello() {
          System.out.println(" in sayHello()");
          return "{ \"status\": \"OKAY\" }";
      }
  
  }
  </code></pre>
  
  <p>The context path is "\foo".<br>
  My Filter is supposed to convert the POST request
  <a href="http://localhost:8080/foo/dispatcher/controller/action" rel="nofollow noreferrer">http://localhost:8080/foo/dispatcher/controller/action</a><br>
  to<br>
  <a href="http://localhost:8080/foo/newdispatcher/helloworld" rel="nofollow noreferrer">http://localhost:8080/foo/newdispatcher/helloworld</a></p>
  
  <p>As I said above, Jersey does not have a problem if i enter this target request in the browser (get), or a POST request via Postman.</p>
  
  <p>My Filter, starts as follows:</p>
  
  <pre><code>package com.test;
  
  //a bunch of imports
  
  @WebFilter(filterName = "ombFilter")    
  public class OmbFilter  implements Filter {
  </code></pre>
  
  <p>The filter, upon detecting the request that needs to be replaced, creates a HttpServletRequestWrapper and forwards it:</p>
  
  <pre><code>servletRequest = new RedirectHttpServletRequestWrapper(request);
  servletRequest.getRequestDispatcher("/helloworld").forward(servletRequest, servletResponse);
  </code></pre>
  
  <p>The wrapper is implemented as follows (simplified):</p>
  
  <pre><code>class RedirectHttpServletRequestWrapper extends HttpServletRequestWrapper {
          public RedirectHttpServletRequestWrapper(HttpServletRequest request) {
              super(request);             
          }
  
          //tried with and without this
          //@Override public String getMethod() { return "GET"; }
  
          @Override public String getPathInfo() { return "/helloworld"; }
  
          @Override public String getRequestURI() {   
              return "/foo/newdispatcher/helloworld";
          }
  
          @Override
          public StringBuffer getRequestURL() {
              return new StringBuffer(
                 "http://localhost:8080/foo/newdispatcher/helloworld");
          }
  
          @Override public String getServletPath() { return "/newdispatcher"; }
      }
  </code></pre>
  
  <p>The web.xml contains the following:</p>
  
  <pre><code>&lt;servlet&gt;
      &lt;servlet-name&gt;RESTful Jersey Hello World Service&lt;/servlet-name&gt;
      &lt;servlet-class&gt;org.glassfish.jersey.servlet.ServletContainer&lt;/servlet-class&gt;
      &lt;init-param&gt;
          &lt;param-name&gt;jersey.config.server.provider.packages&lt;/param-name&gt;
          &lt;param-value&gt;com.test&lt;/param-value&gt;
      &lt;/init-param&gt;
      &lt;load-on-startup&gt;1&lt;/load-on-startup&gt;
    &lt;/servlet&gt;
  
    &lt;servlet-mapping&gt;
      &lt;servlet-name&gt;RESTful Jersey Hello World Service&lt;/servlet-name&gt;
      &lt;url-pattern&gt;/newdispatcher/*&lt;/url-pattern&gt;
    &lt;/servlet-mapping&gt;
  
    &lt;!-- can this be causing the problem? --&gt;
    &lt;filter-mapping&gt;
      &lt;filter-name&gt;ShiroFilter&lt;/filter-name&gt;
      &lt;url-pattern&gt;/*&lt;/url-pattern&gt;
      &lt;dispatcher&gt;REQUEST&lt;/dispatcher&gt;
      &lt;dispatcher&gt;FORWARD&lt;/dispatcher&gt;
      &lt;dispatcher&gt;INCLUDE&lt;/dispatcher&gt;
      &lt;dispatcher&gt;ERROR&lt;/dispatcher&gt;
    &lt;/filter-mapping&gt;
  
    &lt;filter-mapping&gt;
      &lt;filter-name&gt;ombFilter&lt;/filter-name&gt;
      &lt;url-pattern&gt;/dispatcher/controller/*&lt;/url-pattern&gt;
    &lt;/filter-mapping&gt;
  </code></pre>
  
  <p>Update:
  Since the client sending the request which My filter is "redirecting", may be different than the browser/Postman, Here are some of the request headers that the client is sending with the request:</p>
  
  <pre><code>Accept:application/json, text/plain, */*
  Accept-Encoding:gzip, deflate, br
  Accept-Language:en-US,en;q=0.8
  Cache-Control:no-cache
  Connection:keep-alive
  Content-Length:220
  Content-Type:application/x-www-form-urlencoded
  </code></pre>
  
  <p>Would any of these cause Jax-RS to fail in matching this request to the methods in my resource class HelloWorld?<br>
  Perhaps I need to add some more/different annotations to the methods there such as @Consumes? (tried @Consumes(MediaType.APPLICATION_FORM_URLENCODED) because of the request Content-Type)<br>
  Is the Accept-Encoding header the problem?</p>