Hyland Connect

danlangford · ‎05-19-2012

we have written many webscripts and a handful of custom interfaces on Share. when our webscripts encounter a server side error with out other systems we have them return an error like so:


// some-action.get.js returns application/json
model.result = "FAILED: custom, localized exception message";
status.code = 500;
‍‍‍‍‍

until recently we have been using Alfresco 3.4.5. whether we access the webscript via Alfresco (/alfresco/s/org/some-action) or via Shares proxy (/share/proxy/alfresco/org/some-action) our error would be propagated to the client as expected:


{"result" : "FAILED: custom, localized exception message"}
‍‍‍

we recently upgraded to Alfresco 4.0. everything DID stay consistent when accessing the webscripts via Alfresco (/alfresco/s/org/some-action). HOWEVER on Share (/share/proxy/alfresco/org/some-action) its a different story. everything works for status codes of 200 but not for errors like 500 or 403. in the case that our scripts return an error of 500 with a type of application/json i can step through the java stack at runtime and see tomcats StandardHostValve change the type to text/html and load up error500.jsp. (some of) the contents of that page are stuffed into the response in tomcats ErrorReportValve. so the client gets back a 500 Internal Error type text/html and then just a partial response that looks like the head of the error500.jsp page. then the clientJS errors out trying to parse what was supposed to be JSON. no error or messages of interest where placed in any logs.

its literally just a partial response. here is the response:


<html><head><title>Apache Tomcat/6.0.35 - Error report</title><style><!–H1 {font-family:Tahoma,Arial,sans-serif;
‍‍‍

( interesting side note: i always get as much of the error500.jsp page as is proportionate to the length of my original custom error mesage. the longer the message the more of the page i get back. has to do with reusing the response body outputbuffer. thought it was funny. and its an issue probably for the tomcat team )

i think it maybe related to these:
http://osdir.com/ml/users-tomcat.apache.org/2012-04/msg00305.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=53071

then i stumbled across this Alfresco jira issue that MIGHT have something to do with it. it looks like this was added as a feature of Alfresco 3.4.9. ALF-9861

I dont know a lot about tomcat and the Share proxy. i was hoping its some sort of a configuration issue that i could override but i dont know how to move forward. here is what i have tried:

sending back another 500 error, like 501 or 555 in hopes that it was 500 specific. i do get the correct error number, but still a portion of the error500.jsp is shoved over my response body

setting status.redirect=true. the response is still destroyed by Shares proxy

setting my custom error in status.message. that is also overwritten by Shares proxy.

removing the error page declaration in Shares web.xml. this just started overwriting my custom error with a tomcat 404 status and page. and this would also cause Share to not have any error page for even it's own 500s.

now since my Alfresco Explorer and Share are running on same domain and port i could make a call straight to Alfresco instead of using the proxy. Also, even if our Alresco was moved to even a different domain i could use JSONP (callback=) to get to it. i do recognize those as valid work arounds. i am however still curious to know a few things:

i am even executing the idea of custom error messages correctly? is there another preferred way that i should be sending those back that Shares proxy wont overwrite?

Or is there a simple way to configure Share not to overwrite my custom response?

if its an issue with shares proxy configuration then i think i posted in the correct place. if its a problem with how i should be propograting my error messages from a webscript then i suppose i should have posted this elsewhere. forgive me.

any hints or ideas are welcome. thank you for your time and consideration. if i have been unclear let me know and i will try to clarify.
thank you

flm · ‎06-11-2012

I am facing this issue as well. I opened a ticket with Alfresco support because even the JSON error result of the default document library actions is not available anymore.

Since the Share implementation doesn't seem to use these as error messages, it is not apparent in the Share App but we use these messages in our custom code.

kevinr · ‎06-12-2012

Thank you for raising the issue with detailed information. The behaviour of error handling you mention was changed to fix a number of customer issues relating to the fact that we did *not* allow the J2EE container to handle the 500 errors. The customers wished to customise the 500 JSP error page (and potentially add other errorXYZ.jsp pages).

My apologies that this is has broken your customisations. I will looking into a solution ASAP.

Cheers,

Kev

flm · ‎06-12-2012

As a reference, these are two Jira issues related to this problem:
https://issues.alfresco.com/jira/browse/ALF-14524
https://issues.alfresco.com/jira/browse/ALF-14451

kevinr · ‎06-13-2012

Fixed in 3.4.11 rev 37720.

The fix requires a SpringSurf library update. The latest is now 1.2.0-SNAPSHOT.

The change is very small though, so I can provide a modified spring-webscripts JAR that will work against 3.4.9 or 4.0.1 etc.

Index: spring-webscripts/spring-webscripts/src/main/java/org/springframework/extensions/webscripts/connector/RemoteClient.java
===================================================================
— spring-webscripts/spring-webscripts/src/main/java/org/springframework/extensions/webscripts/connector/RemoteClient.java   (revision 1088)
+++ spring-webscripts/spring-webscripts/src/main/java/org/springframework/extensions/webscripts/connector/RemoteClient.java   (revision 1089)
@@ -1119,7 +1119,7 @@
             if (debug) logger.debug("Response encoding: " + contentType);

             // generate container driven error message response for specific response codes
-            if (res != null && (responseCode == HttpServletResponse.SC_UNAUTHORIZED || responseCode >= HttpServletResponse.SC_INTERNAL_SERVER_ERROR) && allowResponseCommit)
+            if (res != null && responseCode == HttpServletResponse.SC_UNAUTHORIZED && allowResponseCommit)
             {
                 res.sendError(responseCode, method.getStatusText());
             }

Hyland Connect

proxying custom webscript errors