Details

    • Type: Question Question
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta5
    • Fix Version/s: 2.0-beta6
    • Component/s: Core, log4j 1.2 emulation
    • Labels:
      None

      Description

      Not 100% sure, but this code looked a bit strange:
      (o.a.l.l.core.Logger line 65)
      public Logger getParent() {
      final LoggerConfig lc = config.loggerConfig.getParent();
      if (lc == null)

      { return null; }

      if (context.hasLogger(lc.getName()))

      { return context.getLogger(getName(), getMessageFactory()); // <------- }

      return new Logger(context, getName(), this.getMessageFactory()); // <-------
      }

      the last two return statements use the name of this logger instead of the parent name lc.getName().
      Is that correct?

      (this method is not used in core internally but is used in the logtj12-api module, by Category#getParent)
      I'll try to write a JUnit test for this later, still need to figure out how.

        Activity

        Remko Popma created issue -
        Hide
        Nick Williams added a comment -

        That doesn't look right to me, either. The whole thing seems kind of wonky. I'm not sure exactly what the right answer is, but I think that middle part should be this:

        if (context.hasLogger(lc.getName()))

        { return context.getLogger(lc.getName(), getMessageFactory()); // <------- }

        But I don't purport to understand how everything works in this codebase. I could certainly be wrong.

        Show
        Nick Williams added a comment - That doesn't look right to me, either. The whole thing seems kind of wonky. I'm not sure exactly what the right answer is, but I think that middle part should be this: if (context.hasLogger(lc.getName())) { return context.getLogger(lc.getName(), getMessageFactory()); // <------- } But I don't purport to understand how everything works in this codebase. I could certainly be wrong.
        Hide
        Remko Popma added a comment -

        Hmm. This code base is a lot easier to understand than log4j 1.x though!

        Show
        Remko Popma added a comment - Hmm. This code base is a lot easier to understand than log4j 1.x though!
        Hide
        Nick Williams added a comment -

        Preach it! Lol. I've customized Log4j 1.x (locally) before. I never want to do that again...

        Show
        Nick Williams added a comment - Preach it! Lol. I've customized Log4j 1.x (locally) before. I never want to do that again...
        Hide
        Ralph Goers added a comment -

        Are you guys trying to make me blush?

        Show
        Ralph Goers added a comment - Are you guys trying to make me blush?
        Hide
        Ralph Goers added a comment -

        Fix committed in revision 1479236. Created LoggingTest in the log4j-1.2 api package to test this. Please verify and close.

        Show
        Ralph Goers added a comment - Fix committed in revision 1479236. Created LoggingTest in the log4j-1.2 api package to test this. Please verify and close.
        Ralph Goers made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Ralph Goers [ ralph.goers@dslextreme.com ]
        Fix Version/s 2.0-beta6 [ 12324340 ]
        Resolution Fixed [ 1 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        4d 20h 39m 1 Ralph Goers 05/May/13 06:13

          People

          • Assignee:
            Ralph Goers
            Reporter:
            Remko Popma
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development