Creating Struts sends 500 internal server errors when exceptions are received

Question

I am working on an AJAX-enabled JavaScript interface that invokes calls to a Java backend written using Struts. My problem is that when the backend throws an exception, the client still sees the HTTP response code "200 OK" instead of "500 Internal Server Error", as you would expect.

This disables me several times because my third-party JavaScript client library depends on HTTP status codes to determine if something is wrong with the AJAX call, as most modern libraries usually do. Errors go unnoticed until my code explodes when it tries to parse what will usually be JSON.

I really want to avoid hacking my client JS library in order to correctly handle these errors. So, how can I get Struts to give me a 500 status code when there was an unhandled exception in the backend? Should this be the default Struts behavior?

Edit: In this case, the client-side code does not matter. I need to fix the server so that it sends the appropriate status code when unhandled exceptions occur. Thanks!

Answer 1

I figured out how to do this. I'm not sure if this is the best or easiest, but it works. I found the Struts Exception Configuration Guide and added the following to the <package> inside struts.xml :

 <global-results> <result name="exception">/exception.jsp</result> </global-results> <global-exception-mappings> <exception-mapping exception="java.lang.Exception" result="exception" /> </global-exception-mappings> 

This will redirect all unhandled exceptions to /exception.jsp . And here is the content of the JSP:

 <%@ taglib prefix="s" uri="/struts-tags" %> <%@ page contentType="application/json; charset=UTF-8" %> <% response.setStatus(500); %> {"success": false,"errors": "<s:property value="%{exception.message}"/>"} 

In the third line, you will notice that I manually set the response code to 500.

This gave me a new problem: exceptions were no longer logged. As suggested in the above Struts manual, I solved this by adding the following to my <package> in struts.xml :

 <interceptors> <interceptor-stack name="appDefaultStack"> <interceptor-ref name="defaultStack"> <param name="exception.logEnabled">true</param> <param name="exception.logLevel">ERROR</param> </interceptor-ref> </interceptor-stack> </interceptors> <default-interceptor-ref name="appDefaultStack" /> 

Struts: -1 to create such a simple and obvious NOT function by default, and another -1 to make the solution so dumb.

Answer 2

Update : I fixed the <global-results> section (which lacked the httpheader tag)

I like your solution better, but here you can do it in a different way if you don't want to ruin the w / response header setting in jsp.

• In struts.xml, create a global exception mapping from "java.lang.Exception" to the result named "exception"
• In struts.xml, create a global result that maps the "exception" to the httpheader result with a value of 500.
• In web.xml, create an error page entry that maps the 500 error code to your error page location.

So for struts.xml:

 <global-exception-mappings> <exception-mapping exception="java.lang.Exception" result="exception" /> </global-exception-mappings> <global-results> <result name="exception" type="httpheader"> <param name="error">500</param> </result> </global-results> 

And for web.xml

 <error-page> <error-code>500</error-code> <location>/exception.jsp</location> </error-page> 

This works, but has some big disadvantages. The servlet container displays your error page (not struts), so you won’t have access to the original error message or struts valueStack. However, exception logging will still work (if you enable it).

Aside, I also find it puzzling that the racks make it so complicated. In every other structure, I examined the concept of returning a page with an error, and the error code is pretty trivial to implement.

Answer 3

An internal 500 server error is a server-side error, which means that the problem is probably not related to your computer or Internet connection, but that there is a problem with the website server.

This is reported on the client side. It is located on a web server (HTTP server) configured to handle requests.

Answer 4

You did not specify which JS library you are using. I would advise you to carefully read the documentation. If it has some kind of callback method, it should have some responseText other than responseCode . Whenever there is any validation exception on the server side, also report an error. Just don't rely on some exceptions because you are using AJAX. You can track this responseText to display some message, for example, "validation failed for this reason, try again." To agree?

Otherwise, before the response is executed, throw a WebApplicationException :

 throw new javax.ws.rs.WebApplicationException(); // or by any other constructor 

Here is jar