How to Troubleshoot 3 Common Jersey Exceptions
When building a web application, web services are an intrinsic component; without web services to supply data to the browser, the application is very limited in delivering value to the user.
Web applications have come a long way from the days of writing XMLHttpRequest objects from scratch and configuring basic Servlets to respond to the requests – there are many frameworks available that can simplify the web service interaction and save precious development time.
The Digital Agent tech stack includes Backbone.js in the front-end and the Jersey module supplied by the Spring Framework in the back-end. Together these two frameworks make implementing web services a breeze, but there are a few common exceptions that can be frustrating if you’re new to the frameworks and don’t know what they mean (or how to resolve them).
When developing with and debugging Jersey, you may have come across these exceptions (these are all HTTP 500 responses). I’ll use a simple ‘User’ web service to illustrate:
Exception 1: NullPointerException
- @Controller annotation missing
From what I understand, for Spring to allow Jersey to handle requests to a given URL and utilize service-level classes, the ‘@Controller’ annotation must be present in the list of annotations immediately before the class declaration:
@Controller public class UserWebService
If this annotation isn’t present, Spring isn’t aware of how to properly handle the request using the declared services. My first experience with this exception was writing the web service class from scratch, instead of ‘smartly reusing’ another working web service class.
Exception 2: Runtime Exception – com.sun.jersey.api.NotFoundException: null for uri: http://localhost:8080/delegate/services/user
- @Path of web service class missing or web service class not deployed
If you’re just created a new web service and are anxious to see it interact with the front-end of the application, you may run into this exception…because you either missed the @Path annotation or didn’t deploy the most up-to-date web service classes. The class declaration now looks like this:
@Controller
@Path("/services/user")
public class UserWebService
The end result is the same – the front-end makes a request to a URI that Jersey isn’t aware of. Check that the necessary annotation is present and deploy those JAR files!
Exception 3: Runtime Exception – javax.ws.rs.WebApplicationException
- Terminating Rule – @Path of web service class satisfied, but @Path of method not satisfied
This exception can surface when you are adding endpoints to an existing (and working) web service and fail to supply all of the path parameters, such as the ID of a resource.
@GET
@Path("/{id}")
public UserDto getUserById(@PathParam("id") long id)
The root cause is the @Path annotation of a method not being satisfied, in the case of a User web service, a ‘get by ID’ endpoint would require the ID of the user in question – if it’s not supplied (either due to user input or mis-use of a framework), this exception will be thrown.
Bonus! If you see a 404 response from your web service request, the fault is not that of the back-end. Check the URL that your front-end framework is making a request to, chances are it’s incorrect – either a missing leading ‘/’, or a typo in the path parameters.
At the end of the day, despite a few cryptic exceptions, these frameworks will drastically improve development times for web application projects. If (and when) you encounter an exception, it’s a huge time saver if you or someone on your team knows what the root cause is, and can translate the stack trace to plain English for you! Hopefully I’ve provided some human-readable assistance for you and these tips help you out!
