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.