Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 369556 - Logging with log4j: naming of ssl-logger
Summary: Logging with log4j: naming of ssl-logger
Status: CLOSED FIXED
Alias: None
Product: Jetty
Classification: RT
Component: server (show other bugs)
Version: 7.5.4   Edit
Hardware: PC Windows 7
: P3 minor (vote)
Target Milestone: 7.5.x   Edit
Assignee: Greg Wilkins CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-24 12:03 EST by Johannes Röder CLA
Modified: 2012-01-24 12:42 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Röder CLA 2012-01-24 12:03:23 EST
Build Identifier: 7.5.4.v20111024

I'm using log4j for logging, and after upgrading jetty from 7.2.2.v20101205 to 7.5.4.v20111024 my logfiles were polluted with debug-messages, even though the general log-level for jetty is set to "info" by 

    <logger name="org.eclipse.jetty">
        <level value="info" />
    </logger>

in my log4j.xml.

I think I traced the problem back to this 

public static final Logger LOG=Log.getLogger("org.eclipse.jetty.io.nio").getLogger("ssl");

(line 44 in SslSelectChannelEndPoint). I tried adding 

    <logger name="ssl">
        <level value="info" />
    </logger>

to log4j.xml, which does suppress the debug-messages, meaning that (at least for log4j) the above statement results in a logger named "ssl", which hopefully is not intended.

There is a comment in the javadoc of that class saying 'There is a named logger "org.eclipse.jetty.http.ssl"', but I'm not sure if that is intended to be a hint for which logger should have been used or not.

Long story short, I think this behaviour is wrong and the name of the logger should start with "org.eclipse.jetty".

Reproducible: Always
Comment 1 Joakim Erdfelt CLA 2012-01-24 12:42:14 EST
SslSelectChannelEndPoint is no longer present in jetty 7.6+ and jetty 8.1+
Also a quick grep of the codebase also shows no more use of the Log.getLogger().getLogger() technique.