Wow, good catch. That makes perfect sense. We're already using a custom
build of Tuckey that fixes a couple bugs (isn't abandonware great...). We
might just see about plugging that log method into Log4j to get proper
categories and severities out of it. Thanks for the help!
*Ortus Solutions, Corp *
ColdBox Platform: http://www.coldbox.org
On Tue, Apr 3, 2018 at 6:21 PM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
Tuckey does some funky stuff with logging. It basically has its own
that can delegate to slf4j, but if that is not enabled then it will
basically end up logging using the ServletContext log() methods (or
These methods kind of suck, as they have no way to specify a severity or
category. In our impl the version without an exception logs at INFO, the
version with logs at ERROR. Thinking about it these should really have
their own category to make it clear what is going on here.
Other than adding a slf4j bridge and making it use slf4j somehow I don't
know if there is much you can do.
On Wed, Apr 4, 2018 at 7:38 AM, Brad Wood <bdw429s(a)gmail.com> wrote:
> We're using Undertow in a console app that also leverages Tuckey for URL
> rewriting. We're also using Log4j for logging stuff. I was noticing this
> week that most of the log messages from Tuckey seem to be nested inside of
> a log message from Undertow-- often times with a different logging
> [INFO ] io.undertow.servlet: org.tuckey.web.filters.urlrewrite.Condition TRACE:
> I can try and provide the details of how we're using Log4j if I need.
> I'd like to be able to do some filtering and such to separate out my Tuckey
> logs, but I can't do it easily when they appear to get caught up and
> re-logged by Undertow under a different logging category and severity.
> Any ideas on what's going on would be welcome.
> *Developer Advocate*
> *Ortus Solutions, Corp *
> E-mail: brad(a)coldbox.org
> ColdBox Platform: http://www.coldbox.org
> Blog: http://www.codersrevolution.com
> undertow-dev mailing list