I want to know basically what a Jersey filter is and how is it related to a servlet filter? Are they the same? What are the main patterns of using a Jersey Filter?
Technically, a Jersey filter is not a servlet filter. However, you can use a Jersey filter for many of the same things that you would use a servlet filter for - cross-cutting concerns that affect all (or some, or most) the services that Jersey exposes.
As the previous answer states, Jersey comes with two filters, but you can usefully implement the Jersey interfaces ContainerRequestFilter or/and ContainerResponseFilter if you don't want to extend them. You're not limited to these two.
Another Jersey interface to keep in mind is ResourceFilter - this interface can be implemented for a filter that affects only some of the services.
The first part of your question may be answered in the Jersey documentation. A Jersey filter is not the same as a servlet filter.
There are two filters included in Jersey, a filter for logging requests and one for compression (GZip).
Another use case for a custom filter would be authentication or authorization.
Related
I am trying to migrate the usages of Jersey Client in my codebase from com.sun.jersey.client to org.glassfish.jersey.client.
In multiple parts of the codebase I am creating classes that inherit from ClientFilter and override the handle method.
What is the replacement of ClientFilter in Jersey 2 and how should I change the places I use it?
See Jersey docs section Client Filters. Basically there are ClientRequestFilter and ClientResponseFilter. The former is called before the request goes out and the latter is called on the incoming response. See also this post for more info on the flow.
First, Please forgive me for my clumsy English.
[What I want to do]
I want to know #WebServlet annotation by Servlet 3.0 and #Path annotation by Jersey 2.22.2, It is able to using same time?
[That I want is to help]
Can I use two annotations at the same time?
If I can use those annotations, is that way how to use?
Thank you.
#Path annotation defines a path to a RESTful Web service so when you have #Path("/SomeService") it will translate into www.yourapp.com/baseRestUrl/SomeService. You can also define it on the methods which provides REST services. Note that baseRestUrl is defined inside web.xml or in class which extends Application class.
On the other hand #WebServlet("/SomePath") states that Servlet will be listening for request on the www.yourapp.com/SomePath, it is basically replacement of servlet-mapping element in web.xml. You can still configure servlets like this, it's up to you whether you prefer XML or annotation configuration.
I'm investigating a Spring Boot project generated by JHipster and found out that its request mappings aren't done via web.xml nor via Spring's #RequestMapping but like so:
ServletRegistration.Dynamic someServlet =
servletContext.addServlet("someServlet", new SomeServlet());
someServlet.addMapping("/someUrl");
someServlet.setAsyncSupported(true);
My questions are:
Are there any reasonable advantages of dynamic registration instead of classic mapping?
Is it spring-boot's standard of registering mappings or it's just a will of jhipster's owner?
Is someServlet.setAsyncSupported(true) just another way of making response.setHeader("Access-Control-Allow-Origin", "*")?
Is there any reasonable advantages of dynamic registration instead of classic mapping?
Dynamic servlet registration Servlet 3+ way of registering servlets. In Servlets 3 you can avoid creating web.xml and configure application in pure Java. It gives you some advantages like compile time check if everything is fine there and what's more important since you do it in Java code, you can do some additional checks or conditions - for example register particular servlet only if environment property is set or class is available on the classpath.
It's not a replacement for #RequestMapping. In case of Spring Boot you will use it most probably when you want to register some 3rd party servlet - like Dropwizard Metrics servlet in case of JHipster.
Is it spring-boot's standard of registering mappings or it's just a will of jhipster's owner?
There are at least 2 ways of registering additional servlets in Spring Boot. See answers here: How can I register a secondary servlet with Spring Boot?.
Your own controllers you map as usual with #RequestMapping.
Is someServlet.setAsyncSupported(true) just another way of making response.setHeader("Access-Control-Allow-Origin", "*")?
Nope. For setting this header you use usually CORSFilter (read more: Enabling Cross Origin Requests for a RESTful Web Service). asyncSupported flag is used to make servlet able to process request asynchronously.
This question already has an answer here:
What is the difference between a Servlet filter and a Jersey filter?
(1 answer)
Closed 2 years ago.
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?
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.
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.
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
I'm using Stripes 1.5 and I was using a interceptor (based on this example) to prevent unauthorized access to *.action pages.
Now I want to use the same interceptor to prevent access to a servlet.
I've added this this to web.xml (DisplayChart is the servlet I want to protect):
<filter-mapping>
<filter-name>StripesFilter</filter-name>
<servlet-name>DisplayChart</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
But it doesn't work, the interceptor intercept method doesn't execute when accesing the DisplayChart servlet path (even if I #Intercepts all the LifeCycleStage).
Is there a way to a interceptor to execute when another servlet is accesed? Or Stripes filters are not intended to be used that way (and I'll have to use a plain Filter)?
I don't know if you can apply a Stripes interceptor to a non-Stripes servlet.
But i am pretty sure you shouldn't.
The Stripes interceptors are specific to Stripes, and Stripes's request lifecycle. A request to a plain servlet is not a Stripes request, and does not go through this lifecycle, even if it goes through the Stripes filter. Such a request should not use a Stripes interceptor, even if this is possible.
I suggest you factor out the authorization code from your Stripes interceptor into a Stripes-agnostic service class, then write a standard filter which uses that class. Your Stripes interceptor and your filter are then very small bits of code which hand off to the service.
The Stripes filter can't be used like that, as the Stripes filter is actually the Stripes front controller that dispatches only to action beans and possible an Stripes interceptor before that.
So as you already assumed, you need a regular servlet filter.