0

I'm planning on writing a servlet application (meant for deployment with OSGI) and use some filters for HTTP header pre-processing. While originally settled on the javax.servlet filter implementation, it occured to me that I actually don't know why/when one would choose to use that vs the Jersey ContainerRequestFilter. Granted the latter comes with some pre-built filters, but arguably so does the former (eg Cors filter). Thus, what should be considered when choosing which API to use? Are there specific cases when one should not be used in favor of the other?

Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
void4
  • 206
  • 1
  • 4
  • 10
  • 2
    This question is not the same as [link](http://stackoverflow.com/questions/8738366/equivalent-of-servlet-filter-for-jersey-jax-rs-rest-resources), in that it does not ask whether it is possible nor which is the best, but rather what should one consider when choosing. This is also not answered on the other question. – void4 Jun 30 '14 at 19:37

3 Answers3

2

From https://dennis-xlc.gitbooks.io/restful-java-with-jax-rs-2-0-en/cn/part1/chapter12/server_side_filters.html

[...] servlet filters wrap around servlet processing and are run in the same Java call stack. Because JAX-RS has an asynchronous API, JAX-RS filters cannot run in the same Java call stack. Each request filter runs to completion before the JAX-RS method is invoked. [...]

I think, this is a key difference, that should be considered, when choosing the one or the other.

Thomas Schütt
  • 832
  • 10
  • 14
1

The problem with JAX-RS filters is that your are not in control to execute the filter chain

chain.doFilter(request, response);

Because my problem is now to shift a Servlet Filter to a JAX-RS filter but the current Servlet Filter calls the whole filter chain in order to check in the end the response and its status. This is not possible with a JAX-RS filter from my point of view.

kladderradatsch
  • 596
  • 5
  • 18
0

Whatever you decide, you will be using a javax.servlet based Filter implementation, since it is the base interface for every Filter you use in Java EE.

http://docs.oracle.com/javaee/6/api/javax/servlet/Filter.html

Now, Jersey comes with an implementation that adds some functionality (access to your ContainerRequestContext or whatever you would need inside your Jersey application). Are you using Jersey already in your application? Then go for it, if not I would not bother (at least a priori and without further information) and just go for the most simple possible implementation of javax.servlet.Filter and put it straight into my web.xml

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Jorge_B
  • 9,712
  • 2
  • 17
  • 22
  • Thanks. So, accessing the request context is clearly also possible from a Filter implementation (.getHeader(), .getParameter(), etc), but i suppose that ContainerRequestContext provides a bit more finesse in doing so by having various inbuilt getters, etc. – void4 Jun 30 '14 at 19:58
  • 8
    @Jorge_B - I don't see that ContainerRequestFilter extends the servlet Filter interface. Can you please explain what you mean by: "Whatever you decide, you will be using a javax.servlet based Filter implementation, since it is the base interface for every Filter you use in Java EE.". Thanks! – elanh Nov 05 '14 at 15:37
  • 3
    I stand corrected, Jersey implementation does not extend javax.servlet.Filter. In that case you have only the reference to the ContainerRequestContext to interact with the application behavior, and no way to alter the filter chain as in a normal Filter. Thanks for the comment! – Jorge_B Nov 05 '14 at 15:56
  • Can you please elaborate on @elanh question because I am confused as well ? – cafebabe1991 Apr 18 '18 at 15:43