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 
<https://tomcat.apache.org/tomcat-11.0-doc/logging.html#Servlets_logging_API> 
well 
enough to see whether or how this can be changed.

On Wednesday, April 30, 2025 at 12:45:30 AM UTC-5 RobW wrote:

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.

On Tuesday, 29 April 2025 at 21:37:30 UTC+1 Gerard Keiser wrote:

The default implementation of 
AbstractRemoteServiceServlet#doUnexpectedFailure(Throwable) 
<https://www.gwtproject.org/javadoc/latest/com/google/gwt/user/server/rpc/jakarta/AbstractRemoteServiceServlet.html#doUnexpectedFailure(java.lang.Throwable)>
 
calls RPCServletUtils#writeResponseForUnexpectedFailure(ServletContext, 
HttpServletResponse, Throwable) 
<https://www.gwtproject.org/javadoc/latest/com/google/gwt/user/server/rpc/RPCServletUtils.html#writeResponseForUnexpectedFailure(javax.servlet.ServletContext,javax.servlet.http.HttpServletResponse,java.lang.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 
<https://logging.apache.org/log4j/2.x/log4j-jul.html> isn’t a good option 
at the moment, making a wrapper that implements ServletContext seems much 
worse, and replacing the application server logger 
<https://logging.apache.org/log4j/2.x/jakarta.html#replace> didn’t help.

Thanks,
Gerard

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/google-web-toolkit/68e19bcc-2679-4141-bc08-df4bd91f091en%40googlegroups.com.

Reply via email to