I've been reading that the JAX-RS is built on top of servlets. Is this literally true, or it just mean that it is a higher level component? If it is, how does that work? Does JAX-RS create a servlet which parses the request and manually initializes #Path annotated classes and passes the modified parameters to them? The JSR does not seem to specify this, and none of the books that mention it go into any details.
note: I don't have trouble deploying JAX or servlets, I am just curious about the details, as it would provide a better understanding of how the web container works.
I've been reading that the JAX-RS is built on top of servlets. Is this literally true,
Simply put, YES, the JAX-RS specification is built on top of Servlets, and any other deployment method (such as mentioned by #Jilles van Gurp) is implementation specific.
Does JAX-RS create a servlet which parses the request and manually initializes #Path annotated classes and passes the modified parameters to them?
JAX-RS doesn't do anything. It's the implementation (e.g. Jersey, RESTEasy, CXF) that implements the entry point servlet. Does the implementation need to explicitly parse the request? No, not all of it. Most of that stuff is handled by the servlet container. Mainly the implementation will just need to parse the request body (as "request" implies more than just the body, e.g URL, headers).
Basically, everything related to JAX-RS is handled by the implementation. The servlet container has nothing to with anything but passing the HttpServletRequest and HttpServletResponse, just like if you were to implement your own servlet. If you were to make your own JAX-RS implementation, the servlet passing you the HttpServletRequest(Response) is the request entry point, and everything else is up you.
EDIT
as "request" implies more than just the body, e.g URL
Bad example. Actually, the JAX-RS implementation would parse the URL in order to get path parameters and query parameters. Though the Servlet container will parse the URL and add query parameters to the HttpServletRequest parameters map, that map also has form POST parameters, so the implementation will need to do it's own parsing of the query parameters also.
Jax rs does not really use or depend on servlets directly but it is commonly implemented on top of it by frameworks that implement it. In that case your application is wrapped with a servlet that delegates incoming requests to your jax rs endpoints and the whole thing is deployed in a servlet container such as tomcat or jetty.
However, for example jersey (the reference implementation) can run without a servlet wrapper in a standalone server. We use grizzly as our container for this. There is no servlet container in our application and we use the grizzly container instead. Of course the grizzly container provides a very similar execution model but you don't need a full blown application server to run it. go here for more details on grizzly
This is the official documentation of Jboss Resteasy.
RESTeasy is implemented as a ServletContextListener and a Servlet and deployed within a WAR file.
JAX-RS implementations do use ServletAPI for routing and parsing the requests. It is implementation detail and need not be mentioned in the specification.
Related
I'm trying to use Spring Web on Tomcat to build an API server. This is just a request-response API, not a full web app - it won't have any web pages or static assets like images. As such, I think SpringWebMVC is the wrong technology since I don't actually want the MVC part of it, so I'm just just trying to use plain old SpringWeb.
Unfortunately, practically every tutorial I've found online uses the org.springframework.web.servlet.DispatcherServlet which is from the MVC package, not from the base package. In the base package, the only viable HttpServlet implementation I found was org.springframework.web.context.support.HttpRequestHandlerServlet. However, this servlet doesn't seem to honor #RequestMapping or #RequestBody or #ResponseBody annotations in the handler.
I thought perhaps I'd just create multiple handler servlets and just use the url-pattern on each of them in the web.xml to route them correctly, but it turns out url-pattern doesn't support path variables either (at least as far as I can tell).
So is there a way to properly set up this servlet to be able to handle request mappings with path variables like so?:
GET /foo/{fooId}
POST /foo/{fooId}/fooOperation
POST /bar/{barId}/barOperationA
POST /bar/{barId}/barOperationB
POST /bar/{barId}/barOperationC
In a bunch of the tutorials and code samples of Spring Boot and Jersey that I've seen, the following line appears:
register(RequestContextFilter.class)
What is this really used for? I don't see anything unusual in those samples, and if I remove it from my (simple) application, nothing seems to break.
RequestContextFilter's javadoc says
This filter is mainly for use with third-party servlets, e.g. the JSF
FacesServlet. Within Spring's own web support, DispatcherServlet's
processing is perfectly sufficient.
I haven't seen third party servlets in those examples.
In one of them I read
org.glassfish.jersey.server.spring.scope.RequestContextFilter, which
is a Spring filter that provides a bridge between JAX-RS and Spring
request attributes
What would be an example of a Spring request attribute?
What is some typical use case, besides needing a third party servlet?
Is it possible to create a webservice with apache cxf (soap/rest) by "using the servlet transport without Spring and without web.xml file"?
No Its not possible.
The service will be needing the web deployment descriptor.
You can extend
CXFNonSpringJaxrsServlet for REST
and
CXFNonSpringServlet for SOAP
web-services in Apache CXF to avoid using Spring, but then you need to register them in web.xml.
You have to either use Spring configuration or web.xml.
Refer: Apache CXF - How to register a SOAP service without Spring?
It is possible. Took me quite a bit of work to figure this out for my own project and thought I'd share.
In my context, we're using OSGi HTTP Service to publish JAX-RS resources using a Jersey Servlet container and I wanted to do the same thing with CXF for JAX-WS resources.
Your class extending CXFNonSpringServlet should include the following:
private Object obj; // JAX-WS resource singleton
#Override
public void loadBus(ServletConfig conf)
{
super.loadBus(conf);
JaxWsServerFactoryBean factory = new JaxWsServerFactoryBean();
factory.setBus(getBus());
factory.setAddress("/some/path");
factory.setServiceBean(obj);
Server cxfServer = factory.create();
}
Note that you may load as many resources within a single servlet as you find needful. Also note that the path in factory.setAddress() is appended to the path at which you register the servlet.
Also note that I'm using the singleton pattern, rather than the handler-class pattern. I'm sure this could be modified simply to fit the other paradigm.
I am looking for using jersey with embedded Jetty for implementing web APIs for our service. I see code where ServletContextHandler , ServletHolder and all these classes are used to let Jetty know about the Jersey handlers. I am interested to know under the hood, like what happens when we compile this code, how jetty actually discovers the jersey handlers. I know that if I start reading the documentation, I will be able to figure out, however, looking for some quick links that covers this topic. Is there any such link?
Thanks.
Jetty can act as a http server and also a servlet container who deals with the lifecycle of servlets (init, service, destroy)
etc. A servlet is a java class that extends HttpServlet class and can override init, service, destroy methods etc. Once jetty
receives a request whose URL matches with that of a servlet, it loads the servlet in memory (if not already there), calls
service method, and keeps it in memory until it destroys it.
Jersey library has provided a standard way of writing RESTful APIs where classes are annotated with tags like say GET/POST
etc and the URL. These classes are called resource classes. It has also provided a servlet whose name is ServletContainer
to hook up with Jetty's servlet container, that intercepts Jetty's request to process servlet (like for any servlet request to jetty
this is the one class, that receives the request first).
What this servlet does is it examines the request, matches with the resource classes URL that it is informed about, and then transfers
control to that method of that resource class (i think it uses reflection for this routing). Therefore, the resource
classes are not servlet itself, but the ServletContainer class of jersey is the only servlet active in the system.
The list of resource classes ServletContainer knows about is configured by this property called "com.sun.jersey.config.property.packages"
The benefit of using Jersey is implementing your REST APIs is you are using standard way of writing your code that you can
deploy to any other standard servlet container if needed in future like tomcat, ...
Is there a way to remove HTTP response headers like Server and X-Powered-By?
My application is using a Weblogic server. I'm programming in Java using the Spring MVC framework and Hibernate, and using JSP for views.
Depends on where the headers are added. If inside your app, you can use a Spring MVC Interceptor to remove them after your controller calls. If outside your app, you might be able to try a Java EE filter configured in web.xml (the example is security, but the approach will also work for your use case). If its added after that, you may want to look at your web front end (Apache, IIS, what-have-you) to configure a filter there.
UPDATE
This answer describes an approach for removing specific headers, as the HttpServletResponse interface does not allow for header removal explicitly. You will need some trial and error to determine what portion of your stack is adding the header.
If you set concrete responseHeader to null it will be removed / not seen in response headers.