Log4j in doUnexpectedFailure

[Gerard Keiser]

The default implementation of AbstractRemoteServiceServlet#doUnexpectedFailure(Throwable) calls RPCServletUtils#writeResponseForUnexpectedFailure(ServletContext, HttpServletResponse, Throwable), which logs the error with ServletContext#log(String, Throwable). We would like to use Log4j instead. We generally try to avoid overriding methods in 3rd party libraries, but is there another way to swap out the logger? Setting up the JUL-to-Log4j bridge isn’t a good option at the moment, making a wrapper that implements ServletContext seems much worse, and replacing the application server logger didn’t help.

Thanks,

Gerard

[Colin Alworth]

It looks like AbstractRemoteServiceServlet's doUnexpectedFailure method is protected and non-final - it definitely looks appropriate here to override that and follow the same steps. You could also log and then delegate to super.doUnexpectedFailure if you're concerned about changes happening in AbstractRemoteServiceServlet. Such changes are pretty unlikely though - the callsite for that method (in doPost()) explicitly says that doUnexpectedFailure exists to "give a subclass a change to either handle the exception or rethrow it".

Note also that it is totally appropriate to not call super and implement your own logic, as long as you somehow signal failure back to the client. RPCServletUtils.writeResponseForUnexpectedFailure is going to just send back a generic 500 since this is after all an unexpected failure and one that can't take the normal approach of telling the client what happened.

The last link you posted implies that you're using tomcat, is that correct? It seems like this is more of a tomcat configuration problem then - could be worth tracking down in general, rather than hoping no other servlet library uses servlet apis for logging?

Finally, please note that this is not the only way that GWT-RPC is going to call context.log() - see RPCServletUtils.writeResponse for example.

[RobW]

I know you say it's not an option -  but we found JUL bridge to be our least bad long term option. We needed it for one specific library, but now I'd say there's maybe half a dozen edge cases it handles for us. FWIW - we moved to reload4j also as our code is 1.2 and we had no need of log4j 2.

[Gerard Keiser]

Thanks; that’s quite helpful. I will try some more with the JUL bridge, and do the override if it doesn’t work out still.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/238b9e33-97fa-4edd-8070-0d383ee85621n%40googlegroups.com.

[Gerard Keiser]

Thanks. This is very helpful.

The last link you posted implies that you're using tomcat, is that correct? It seems like this is more of a tomcat configuration problem then - could be worth tracking down in general, rather than hoping no other servlet library uses servlet apis for logging?

I know you say it's not an option -  but we found JUL bridge to be our least bad long term option. We needed it for one specific library, but now I'd say there's maybe half a dozen edge cases it handles for us. FWIW - we moved to reload4j also as our code is 1.2 and we had no need of log4j 2.

The biggest issue is writing to application-specific log files. With the bridges I can get more info from ServletContext.log, including the web app context, but it’s only outputting to the main Tomcat log, not to the application log as well. I am not understanding the docs well enough to see whether or how this can be changed.

[Thomas Broyer]

From that doc, you should be able to configure it using a WEB-INF/classes/logging.properties file in your webapp, see the example at the end of the page. If the Tomcat server is under your control, you could also configure it globally for the org.apache.catalina.core.ContainerBase.[Catalina].[${host}].[${context}] category (replace ${host} and ${context} accordingly; again, you can see it done in the example at the end of the page for the manager application (deployed at /manager, that will have its logs in manager.* files)

(I must say I haven't worked with WAR files for more than a decade, and my opinion is that this is only an OK approach if there are ops teams dedicated to managing those servlet containers / application servers, in which case they should know how to deal with those logs; for all other situations, an embedded web server is the way to go, which allows you to use a single logging system for the whole app; ymmv)

[Gerard Keiser]

Thank you. I’ll see if I can get it with that logging.properties.