Setting up your web.xml
To create services that use this transport you can either use the CXF APIs (for example, see JAX-WS) or create an XML file which registers services for you.
Publishing an endpoint from XML
CXF uses Spring to provide XML configuration of services. This means that first we'll want to load Spring via a Servlet listener and tell it where our XML configuration file is:
Next, you'll need to add CXFServlet to your web.xml:
Alternatively, you can point to the configuration file using a CXFServlet init parameter :
The next step is to actually write the configuration file:
Here we're creating a JAX-WS endpoint based on our implementation class, GreeterImpl.
NOTE: We're publishing endpoints "http://localhost/mycontext/services/Greeter1" and "http://localhost/mycontext/services/GreeterRest", but we set jaxws:endpoint/@address and jaxrs:server/@address to relative values such as "/Greeter1" "/GreeterRest".
Support for Asynchronous Requests
Enable an 'async-supported' servlet property if you work with Servlet3 API containers and need to support asynchronous requests:
Redirecting requests and serving the static content
Starting from CXF 2.2.5 it is possible to configure CXFServlet to redirect current requests to other servlets or serve the static resources.
"redirects-list" init parameter can be used to provide a space separated list of URI patterns; if a given request URI matches one of the patterns then CXFServlet will try to find a RequestDispatcher using the pathInfo of the current HTTP request and will redirect the request to it.
"redirect-servlet-path" can be used to affect a RequestDispatcher lookup, if specified then it will concatenated with the pathInfo of the current request.
"redirect-servlet-name" init parameter can be used to enable a named RequestDispatcher look-up, after one of the URI patterns in the "redirects-list" has matched the current request URI.
"static-resources-list" init parameter can be used to provide a space separated list of static resource such as html, css, or pdf files which CXFServlet will serve directly.
One can have requests redirected to other servlets or JSP pages.
CXFServlets serving both JAXWS and JAXRS based endpoints can avail of this feature.
For example, please see this web.xml.
The "http://localhost:9080/the/bookstore1/books/html/123" request URI will initially be matched by the CXFServlet given that it has a more specific URI pattern than the RedirectCXFServlet. After a current URI has reached a jaxrs:server endpoint, the response will be redirected by the JAXRS RequestDispatcherProvider to a "/book.html" address, see "dispatchProvider1" bean here.
Next, the request URI "/book.html" will be handled by RedirectCXFServlet. Note that a uri pattern can be a regular expression. This servlet redirects the request further to a RequestDispatcher capable of handling a "/static/book.html".
Finally, DefaultCXFServlet serves a requested book.html.
Serving welcome pages
Starting from CXF 2.5.5 and 2.6.2 it is possible to configure CXFServlet to serve welcome pages in a number of ways.
For example, lets assume we have a web application called "webapp" which has a root resource called "index.html". For CXFServlet to support both "/webapp" and "/webapp/index.html" requests returning "index.html", while letting all other requests to proceed to the actual endpoints, the following can be done.
Option1. Delegating to Default Servlet
Note that the redirects-list parameter has two space separated values, "/" and "index.html". The request attribute 'javax.servlet.include.request_uri' might need to be set for the underlying container like Jetty to successfully read "index.html".
Option2. Using CXFServlet itself to read index.html
Publishing an endpoint with the API
Once your Servlet is registered in your web.xml, you should set the default bus with CXFServlet's bus to make sure that CXF uses it as its HTTP Transport. Simply publish with the related path "Greeter" and your service should appear at the address you specify:
The one thing you must ensure is that your CXFServlet is set up to listen on that path. Otherwise the CXFServlet will never receive the requests.
Endpoint.publish(...) is a JAX-WS API for publishing JAX-WS endpoints. Thus, it would require the JAX-WS module and APIs to be present. If you are not using JAX-WS or want more control over the published endpoint properties, you should replace that call with the proper calls to the appropriate ServerFactory.
Since CXFServlet know nothing about the web container listening port and the application context path, you need to specify the relative path instead of the full http address.
Using the servlet transport without Spring
A user who doesn't want to touch any Spring stuff could also publish the endpoint with CXF servlet transport. First you should extend the CXFNonSpringServlet and then override the method loadBus, e.g.:
If you are using the Jetty as the embedded servlet engine, you could publish endpoint like this:
Accessing the MessageContext and/or HTTP Request and Response
Sometimes you'll want to access more specific message details in your service implementation. One example might be accessing the actual request or response object itself. This can be done using the WebServiceContext object.
First, declare a private field for the WebServiceContext in your service implementation, and annotate it as a resource:
Then, within your implementing methods, you can access the MessageContext, HttpServletRequest, and HttpServletResponse as follows:
Of course, it is always a good idea to program defensively if using transport-specific entities like the HttpServletRequest and HttpServletResponse. If the transport were changed (for instance to the JMS transport), then these values would likely be null.