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

On Thursday, May 1, 2025 at 9:14:19 AM UTC-5 Thomas Broyer wrote:

> 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)
>
> On Wednesday, April 30, 2025 at 9:39:02 PM UTC+2 Gerard Keiser wrote:
>
>> 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/c15a480e-c5bb-4597-b3e7-b0795b8b9b5dn%40googlegroups.com.

Reply via email to