I am using Jersey restful web services for the Application development.
<servlet>
<servlet-name>Jersey Web Application</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>com.services</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
I have some service classes configured under com.services package.
Basically my requirement is that, before Jersey calling my Service classes, i want to do some initial check.
Basically my requirement is that before invoking the service, i want to check if a input hidden variable passed from UI is present or not.
So is it possible to extend the Jersey Framework for acheving this?
Could you please tell me how can i use this inside my service class ??
@Path("/hello")
public class HelloService extends AbstractService {
@GET
@Produces("application/text")
public String sayPlainTextHello() {
return "Hello json";
}
}
Introduction
Here’s a simple solution that should suit your use case pretty well. What I’m showing here is not how to perform operations before a service is called but rather, immediately after the service is called and before the code of your resource methods is executed. Still, it seems like a good thing to do, judging by your description of the problem.
You can create your own parameter classes to do whatever you wish with form input (parsing strings, validation, etc.). Just make sure you have a constructor that takes a
Stringparameter and you’ll be able to inject appropriate objects into the calls of the methods of your resource classes. If the value is incorrect, throw an exception specifying the message and status code for Jersey to return to the client.Example
Given the form
create a parameter class like this:
Then, in you resource class, inject the parameter:
Notice that you don’t have to do anything to
hiddenin the code of this method. You can perform all validation in a transparent manner within the code of your parameter class. The checks don’t have to be repeated over and over, they don’t pollute your resource classes.It also makes for an easily testable solution, which can be made even simpler by using a generic parameter class (less code repetition).
Such classes can be used with
@QueryParamand@PathParamannotations as well.