Errorneous usage of HttpServletResponse in the rest endpoints

The various rest services follow the pattern:

if (some_condition) {
    sendErrorXXX(response, message); //send the error response
    return Response.status(Status.ERROR_STATUS).build(); //sending the error response again
}

The various “sendErrorXXXX” methods in AbstractRestService are unnecessary and duplicate the behavior of the returned Response object. Even more - it’s an error to use both. The proper way to send any kind of response in JAX-RS is to use the ResposneBuilder. JAX-RS endpoints should avoid touching the HttpServletResponse directly.

[g051051]

I actually took the opposite tack, and changed the implementation of the methods to all be in the form of:

/** * Create error response not found. * * @param message * the message * @return the error response */ protected Response createErrorResponseNotFound(String message) { return Response.serverError().status(Status.NOT_FOUND).entity(message).build(); }

then updated all the references to just do something like:

return createErrorResponseNotFound(path);

I don’t see this as worse, but I can do it the other way if it’s somehow preferable.

[g051051]

1. Local build was successful. Deployment of dirigible-desktop-all to local Apache Tomcat successful.
2. I tested the following samples:

• Hello World: produced “Hello World” output.
• Bookstore Application: worked as expected.
• HTML5 (AngularJS): worked as expected.
• Message Listener: The IDE shows an error the “exports is not defined” for the handler.js file, but the output is logged as expected. I think this is an existing error in the sample.
• Websocket Service: Same “exports is not defined” error in the IDE, but the output is logged as expected.

1. http://localhost:8080/services/v4/web/not-existing-project/not-existing-page/ produces and error page with: “Resource not found: not-existing-project/not-existing-page/index.html”.