dependency injection and loggers

Discussion in 'Java' started by Tomer, Jan 4, 2013.

  1. Tomer

    Tomer Guest

    I love the concept of dependency injection via ctor. it simplifies life and makes testing easy.
    what about logger?
    i usually instantiate it in private static logger = Logger.getLogger(myclass);
    however this is not dependency injection, should I pass the logger into each ctor? this would look wierd... so what to do about loggers and depedency injection?

    thanks
    Tomer, Jan 4, 2013
    #1
    1. Advertising

  2. Tomer

    markspace Guest

    On 1/4/2013 4:00 AM, Tomer wrote:
    > I love the concept of dependency injection via ctor. it simplifies
    > life and makes testing easy. what about logger? i usually instantiate
    > it in private static logger = Logger.getLogger(myclass); however this
    > is not dependency injection, should I pass the logger into each ctor?
    > this would look wierd... so what to do about loggers and depedency
    > injection?



    I agree with you on both counts. Ctors are an excellent way of
    implementing dependency injection, and static methods aren't.

    However loggers are more of an aspect than a dependency. Absent some
    other framework (AOP, for example, or some sort of annotation
    processing), good old frameworks and libraries solve this problem. Have
    a look at Apache logging:

    <http://commons.apache.org/logging/>
    markspace, Jan 4, 2013
    #2
    1. Advertising

  3. In article <kc6rjn$fl2$>,
    markspace <> wrote:

    > On 1/4/2013 4:00 AM, Tomer wrote:
    > > I love the concept of dependency injection via ctor. it simplifies
    > > life and makes testing easy. what about logger? i usually instantiate
    > > it in private static logger = Logger.getLogger(myclass); however this
    > > is not dependency injection, should I pass the logger into each ctor?
    > > this would look wierd... so what to do about loggers and depedency
    > > injection?

    >
    >
    > I agree with you on both counts. Ctors are an excellent way of
    > implementing dependency injection, and static methods aren't.
    >
    > However loggers are more of an aspect than a dependency. Absent some
    > other framework (AOP, for example, or some sort of annotation
    > processing), good old frameworks and libraries solve this problem. Have
    > a look at Apache logging:
    >
    > <http://commons.apache.org/logging/>


    I'd say that Java's own logger (java.util.logging) is worth a look too
    if you want modularity. It's easy to plug in custom formatters and
    handlers. You map logging paths to handlers during app initialization
    so no dependency injection is involved. My biggest peeve about most
    loggers is that they don't indent multi-line log entries nicely and
    they're sensitive to disk latency. It's not a problem when you plug in
    your own parts. You can also do fancy logging to remote archiving
    systems (JSON or XML over socket or REST, etc.) with little effort.

    http://docs.oracle.com/javase/6/docs/api/java/util/logging/package-summar
    y.html
    --
    I will not see posts from Google because I must filter them as spam
    Kevin McMurtrie, Jan 4, 2013
    #3
  4. Tomer

    Daniel Pitts Guest

    On 1/4/13 7:13 AM, markspace wrote:
    > On 1/4/2013 4:00 AM, Tomer wrote:
    >> I love the concept of dependency injection via ctor. it simplifies
    >> life and makes testing easy. what about logger? i usually instantiate
    >> it in private static logger = Logger.getLogger(myclass); however this
    >> is not dependency injection, should I pass the logger into each ctor?
    >> this would look wierd... so what to do about loggers and depedency
    >> injection?

    >
    >
    > I agree with you on both counts. Ctors are an excellent way of
    > implementing dependency injection, and static methods aren't.
    >
    > However loggers are more of an aspect than a dependency. Absent some
    > other framework (AOP, for example, or some sort of annotation
    > processing), good old frameworks and libraries solve this problem. Have
    > a look at Apache logging:
    >
    > <http://commons.apache.org/logging/>
    >
    >

    Loggers can generally be configured externally to their instances.
    Therefor you don't usually need to inject them.

    On the other hand, there generally isn't any real requirement that
    loggers be static. I have had occasion to create a class which uses a
    different logger depending on the context in which that class was created.

    public class MySomething {
    private final Logger log;

    public MySomething() {
    this.log = Logger.getLogger(MySomething.class);
    }
    public MySomething(Logger log) {
    this.log = log;
    }
    }
    Daniel Pitts, Jan 4, 2013
    #4
  5. Tomer

    Lew Guest

    Daniel Pitts wrote:
    > On the other hand, there generally isn't any real requirement that
    > loggers be static. I have had occasion to create a class which uses a
    > different logger depending on the context in which that class was created.
    >
    > public class MySomething {
    > private final Logger log;
    >
    > public MySomething() {
    > this.log = Logger.getLogger(MySomething.class);
    > }
    >
    > public MySomething(Logger log) {
    > this.log = log;
    > }
    > }


    If I have a class hierarchy (for when despite Josh Bloch's recommendation to "prefer composition
    to inheritance" I go the other way) I will often put in the parent class:

    private final Logger logger = Logger.getLogger(getClass().getName());

    This despite the violation of "Don't call an overrideable method during construction."

    :)

    --
    Lew
    Lew, Jan 4, 2013
    #5
  6. Tomer

    Daniel Pitts Guest

    On 1/4/13 11:36 AM, Lew wrote:
    > Daniel Pitts wrote:
    >> On the other hand, there generally isn't any real requirement that
    >> loggers be static. I have had occasion to create a class which uses a
    >> different logger depending on the context in which that class was created.
    >>
    >> public class MySomething {
    >> private final Logger log;
    >>
    >> public MySomething() {
    >> this.log = Logger.getLogger(MySomething.class);
    >> }
    >>
    >> public MySomething(Logger log) {
    >> this.log = log;
    >> }
    >> }

    >
    > If I have a class hierarchy (for when despite Josh Bloch's recommendation to "prefer composition
    > to inheritance" I go the other way) I will often put in the parent class:
    >
    > private final Logger logger = Logger.getLogger(getClass().getName());
    >
    > This despite the violation of "Don't call an overrideable method during construction."
    >
    > :)
    >

    getClass() is not overrideable.
    Daniel Pitts, Jan 4, 2013
    #6
  7. Tomer

    Arne Vajhøj Guest

    On 1/4/2013 7:00 AM, Tomer wrote:
    > I love the concept of dependency injection via ctor. it simplifies life and makes testing easy.
    > what about logger?
    > i usually instantiate it in private static logger = Logger.getLogger(myclass);
    > however this is not dependency injection, should I pass the logger into each ctor? this would look wierd... so what to do about loggers and depedency injection?


    If you do not use a logger hierarchy, then DI'ing loggers would be easy.

    But you typical do so DI is difficult.

    Arne
    Arne Vajhøj, Jan 5, 2013
    #7
  8. Tomer

    Arne Vajhøj Guest

    On 1/4/2013 12:18 PM, Kevin McMurtrie wrote:
    > In article <kc6rjn$fl2$>,
    > markspace <> wrote:
    >> Absent some
    >> other framework (AOP, for example, or some sort of annotation
    >> processing), good old frameworks and libraries solve this problem. Have
    >> a look at Apache logging:
    >>
    >> <http://commons.apache.org/logging/>

    >
    > I'd say that Java's own logger (java.util.logging) is worth a look too
    > if you want modularity. It's easy to plug in custom formatters and
    > handlers.


    log4j has more than jul.

    But if jul has sufficient, then it is obviously fine.

    > My biggest peeve about most
    > loggers is that they don't indent multi-line log entries nicely


    I would recommend avoiding multi-line entries completely.

    Arne
    Arne Vajhøj, Jan 5, 2013
    #8
  9. Tomer

    Arne Vajhøj Guest

    On 1/4/2013 1:31 PM, Daniel Pitts wrote:
    > On 1/4/13 7:13 AM, markspace wrote:
    >> Absent some
    >> other framework (AOP, for example, or some sort of annotation
    >> processing), good old frameworks and libraries solve this problem. Have
    >> a look at Apache logging:
    >>
    >> <http://commons.apache.org/logging/>
    >>

    > Loggers can generally be configured externally to their instances.
    > Therefor you don't usually need to inject them.
    >
    > On the other hand, there generally isn't any real requirement that
    > loggers be static.


    Typically non static logger refs will point to same
    logger object.

    Arne
    Arne Vajhøj, Jan 5, 2013
    #9
  10. On 01/05/2013 12:33 AM, Wayne wrote:
    > On 1/4/2013 10:27 PM, Arne Vajhøj wrote:
    >> On 1/4/2013 12:18 PM, Kevin McMurtrie wrote:
    >>> In article <kc6rjn$fl2$>,
    >>> markspace <> wrote:
    >>>> Absent some
    >>>> other framework (AOP, for example, or some sort of annotation
    >>>> processing), good old frameworks and libraries solve this problem. Have
    >>>> a look at Apache logging:
    >>>>
    >>>> <http://commons.apache.org/logging/>
    >>>
    >>> I'd say that Java's own logger (java.util.logging) is worth a look too
    >>> if you want modularity. It's easy to plug in custom formatters and
    >>> handlers.

    >>
    >> log4j has more than jul.
    >>
    >> But if jul has sufficient, then it is obviously fine.
    >>
    >>> My biggest peeve about most
    >>> loggers is that they don't indent multi-line log entries nicely

    >>
    >> I would recommend avoiding multi-line entries completely.
    >>
    >> Arne
    >>

    >
    > Arne is right. Permitting multi-line log entries is a security
    > hazard. (It is safe to format log entries with multiple lines; but
    > you need to sanitize user data (e.g., strip CR/LF) before including
    > such data in your log messages.)
    >

    Errr, having multiline log entries is not a security hazard, not even
    remotely. Splunk certainly doesn't think so - that toolset has extensive
    configuration capabilities for handling multiline entries.

    What *is* a hazard is if external input to a log entry, that might be
    maliciously seeded with linefeeds, is not sanitized/conditioned. Which
    is what you said. This is actually a CERT secure coding guideline. Point
    being, if you are controlling log entry input, and *you* want a
    linefeed, fill your boots. It's not insecure. Just don't let accidental
    or malicious ones be supplied across a trust boundary.

    I do agree with Arne that multiline should be avoided. Mainly because
    it's a PITA. Not everyone is using Splunk.

    AHS
    Arved Sandstrom, Jan 5, 2013
    #10
  11. In article <H1YFs.44812$>,
    Arved Sandstrom <> wrote:

    > On 01/05/2013 12:33 AM, Wayne wrote:
    > > On 1/4/2013 10:27 PM, Arne Vajhøj wrote:
    > >> On 1/4/2013 12:18 PM, Kevin McMurtrie wrote:
    > >>> In article <kc6rjn$fl2$>,
    > >>> markspace <> wrote:
    > >>>> Absent some
    > >>>> other framework (AOP, for example, or some sort of annotation
    > >>>> processing), good old frameworks and libraries solve this problem. Have
    > >>>> a look at Apache logging:
    > >>>>
    > >>>> <http://commons.apache.org/logging/>
    > >>>
    > >>> I'd say that Java's own logger (java.util.logging) is worth a look too
    > >>> if you want modularity. It's easy to plug in custom formatters and
    > >>> handlers.
    > >>
    > >> log4j has more than jul.
    > >>
    > >> But if jul has sufficient, then it is obviously fine.
    > >>
    > >>> My biggest peeve about most
    > >>> loggers is that they don't indent multi-line log entries nicely
    > >>
    > >> I would recommend avoiding multi-line entries completely.
    > >>
    > >> Arne
    > >>

    > >
    > > Arne is right. Permitting multi-line log entries is a security
    > > hazard. (It is safe to format log entries with multiple lines; but
    > > you need to sanitize user data (e.g., strip CR/LF) before including
    > > such data in your log messages.)
    > >

    > Errr, having multiline log entries is not a security hazard, not even
    > remotely. Splunk certainly doesn't think so - that toolset has extensive
    > configuration capabilities for handling multiline entries.
    >
    > What *is* a hazard is if external input to a log entry, that might be
    > maliciously seeded with linefeeds, is not sanitized/conditioned. Which
    > is what you said. This is actually a CERT secure coding guideline. Point
    > being, if you are controlling log entry input, and *you* want a
    > linefeed, fill your boots. It's not insecure. Just don't let accidental
    > or malicious ones be supplied across a trust boundary.
    >
    > I do agree with Arne that multiline should be avoided. Mainly because
    > it's a PITA. Not everyone is using Splunk.
    >
    > AHS


    There's absolutely nothing wrong with multi-line log messages. This
    brings me around to many loggers not formatting correctly. It should be
    something safe and easy to read like this:

    YYYY/MM/DD META META META Log message line one
    Log message line two
    Log message line three
    Log message line four

    This makes stack traces and long diagnostic messages look good while
    also preventing log spoofing. A spoof attempt would look like:

    YYYY/MM/DD META META META Malicious message line one
    YYYY/MM/DD META META META Malicious message line two

    That second line isn't fooling anything because it starts with a TAB
    character. This feature belongs in the log formatter so it's not
    junking up the rest of the codebase.
    --
    I will not see posts from Google because I must filter them as spam
    Kevin McMurtrie, Jan 5, 2013
    #11
  12. On 1/5/2013 1:01 PM, Kevin McMurtrie wrote:
    > In article <H1YFs.44812$>,
    > Arved Sandstrom <> wrote:
    >> On 01/05/2013 12:33 AM, Wayne wrote:
    >>> On 1/4/2013 10:27 PM, Arne Vajhøj wrote:
    >>>> On 1/4/2013 12:18 PM, Kevin McMurtrie wrote:
    >>>>> My biggest peeve about most
    >>>>> loggers is that they don't indent multi-line log entries nicely
    >>>>
    >>>> I would recommend avoiding multi-line entries completely.
    >>>
    >>> Arne is right. Permitting multi-line log entries is a security
    >>> hazard. (It is safe to format log entries with multiple lines; but
    >>> you need to sanitize user data (e.g., strip CR/LF) before including
    >>> such data in your log messages.)
    >>>

    >> Errr, having multiline log entries is not a security hazard, not even
    >> remotely. Splunk certainly doesn't think so - that toolset has extensive
    >> configuration capabilities for handling multiline entries.
    >>
    >> What *is* a hazard is if external input to a log entry, that might be
    >> maliciously seeded with linefeeds, is not sanitized/conditioned. Which
    >> is what you said. This is actually a CERT secure coding guideline. Point
    >> being, if you are controlling log entry input, and *you* want a
    >> linefeed, fill your boots. It's not insecure. Just don't let accidental
    >> or malicious ones be supplied across a trust boundary.
    >>
    >> I do agree with Arne that multiline should be avoided. Mainly because
    >> it's a PITA. Not everyone is using Splunk.

    >
    > There's absolutely nothing wrong with multi-line log messages. This
    > brings me around to many loggers not formatting correctly. It should be
    > something safe and easy to read like this:
    >
    > YYYY/MM/DD META META META Log message line one
    > Log message line two
    > Log message line three
    > Log message line four
    >
    > This makes stack traces and long diagnostic messages look good while
    > also preventing log spoofing. A spoof attempt would look like:
    >
    > YYYY/MM/DD META META META Malicious message line one
    > YYYY/MM/DD META META META Malicious message line two
    >
    > That second line isn't fooling anything because it starts with a TAB
    > character. This feature belongs in the log formatter so it's not
    > junking up the rest of the codebase.


    Still a bad approach.

    All the log reading tools out there do not understand this
    format.

    Arne
    Arne Vajhøj, Jan 5, 2013
    #12
  13. Tomer

    Lew Guest

    Arne Vajhøj wrote:
    > Kevin McMurtrie wrote:
    >> My biggest peeve about most
    >> loggers is that they don't indent multi-line log entries nicely

    >
    > I would recommend avoiding multi-line entries completely.


    I'm not sure which side of the debate this supports, but for log files the
    single largest issue tends to be readability.

    On most projects I've seen, programmers (including me) toss log statements
    rather willy-nilly into the code, if we use them at all.

    Many programmers (not including me) threw fancy-schmancy emphasis into their
    logs, such as

    logger.debug("* ====== variable not yet assigned or assigned to null ====== *!");

    Note I deliberately chose 'debug' level to emphasize the point, which is that
    in the morass of detail log messages, combined with the boilerplate of
    date, thread ID, log level, etc., this stuff makes it deucedly hard to extract
    information that is

    actually useful for troubleshooting

    ..

    No one looks at the logs until they need them, and then, OMFG crappy log
    statements make life hard. "===" just distracts, and what variable? Where?

    Personally I find terse, info-laden log statements with intelligent use of
    the verbosity hierarchy in a consistent pattern sprinkled with low-level
    stacktraces as required serve best.

    Live downstream of your own effluents - use your own log output to trace and
    troubleshoot your code. Make trouble for your code just so you can do that.

    Getting screwed by your own log output is very instructive. I've been there..

    --
    Lew
    Lew, Jan 5, 2013
    #13
  14. On 1/5/2013 1:01 PM, Kevin McMurtrie wrote:
    > There's absolutely nothing wrong with multi-line log messages. This
    > brings me around to many loggers not formatting correctly. It should be
    > something safe and easy to read like this:
    >
    > YYYY/MM/DD META META META Log message line one
    > Log message line two
    > Log message line three
    > Log message line four
    >
    > This makes stack traces and long diagnostic messages look good while
    > also preventing log spoofing. A spoof attempt would look like:
    >
    > YYYY/MM/DD META META META Malicious message line one
    > YYYY/MM/DD META META META Malicious message line two
    >
    > That second line isn't fooling anything because it starts with a TAB
    > character. This feature belongs in the log formatter so it's not
    > junking up the rest of the codebase.


    It is indeed a formatter/layout issue.

    And it is trivial to do if one want to.

    import java.util.logging.LogRecord;
    import java.util.logging.SimpleFormatter;

    public class IndentSimpleFormatter extends SimpleFormatter {
    @Override
    public String format(LogRecord rec) {
    return super.format(rec).replaceAll("\r\n(?!$)", "\r\n ");
    }
    }


    or:

    import org.apache.log4j.PatternLayout;
    import org.apache.log4j.spi.LoggingEvent;

    public class IndentPatternLayout extends PatternLayout {
    @Override
    public String format(LoggingEvent event) {
    return super.format(event).replaceAll("\r\n(?!$)", "\r\n ");
    }
    }

    Arne
    Arne Vajhøj, Jan 5, 2013
    #14
  15. Tomer

    Arne Vajhøj Guest

    On 1/5/2013 3:24 PM, Lew wrote:
    > Arne Vajhøj wrote:
    >> Kevin McMurtrie wrote:
    >>> My biggest peeve about most
    >>> loggers is that they don't indent multi-line log entries nicely

    >>
    >> I would recommend avoiding multi-line entries completely.

    >
    > I'm not sure which side of the debate this supports, but for log files the
    > single largest issue tends to be readability.
    >
    > On most projects I've seen, programmers (including me) toss log statements
    > rather willy-nilly into the code, if we use them at all.
    >
    > Many programmers (not including me) threw fancy-schmancy emphasis into their
    > logs, such as
    >
    > logger.debug("* ====== variable not yet assigned or assigned to null ====== *!");
    >
    > Note I deliberately chose 'debug' level to emphasize the point, which is that
    > in the morass of detail log messages, combined with the boilerplate of
    > date, thread ID, log level, etc., this stuff makes it deucedly hard to extract
    > information that is actually useful for troubleshooting.
    >
    > No one looks at the logs until they need them, and then, OMFG crappy log
    > statements make life hard. "===" just distracts, and what variable? Where?
    >
    > Personally I find terse, info-laden log statements with intelligent use of
    > the verbosity hierarchy in a consistent pattern sprinkled with low-level
    > stacktraces as required serve best.


    True.

    The content of the message is obviously very important.

    Arne
    Arne Vajhøj, Jan 5, 2013
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?iso-8859-1?B?bW9vcJk=?=

    How to build a dependency injection framework by myself?

    =?iso-8859-1?B?bW9vcJk=?=, Aug 24, 2006, in forum: Java
    Replies:
    4
    Views:
    389
    PerfectDayToChaseTornados
    Aug 24, 2006
  2. Michael Feathers

    Dependency Injection in C++

    Michael Feathers, Oct 11, 2006, in forum: C++
    Replies:
    5
    Views:
    7,375
    F.J.K.
    Oct 13, 2006
  3. Anonieko

    What is Dependency Injection?

    Anonieko, Oct 14, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    293
    Michael Nemtsev, MVP
    Oct 14, 2007
  4. Rhino
    Replies:
    8
    Views:
    500
    markspace
    Apr 30, 2010
  5. PerfectDayToChaseTornados
    Replies:
    5
    Views:
    122
Loading...

Share This Page