Log4j 2
  1. Log4j 2
  2. LOG4J2-167

ClassCastException from SimpleLoggerContext to core.LoggerContext, since it implements spi.LoggerContext

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta5
    • Fix Version/s: 2.0-beta5
    • Component/s: Core
    • Labels:
      None

      Description

      When calling Configurator.initialize(<Name>, null, <File>) it calls LogManager.getContext(loader, false) and if no logging implementation can be found this method returns a new SimpleLoggerContext (created by the factory which in turn is created in the static part of the class). This class implements spi.LoggerContext but the Configurator tries to cast it to core.LoggerContext, which fails since SimpleLoggerContext does not extend that class.

        Activity

        Hide
        Ralph Goers added a comment -

        How did you call Configurator.initialize in such a way that the implementation found in log4j-core couldn't be located?

        Show
        Ralph Goers added a comment - How did you call Configurator.initialize in such a way that the implementation found in log4j-core couldn't be located?
        Hide
        Eric Schellhammer added a comment -

        I tried to use it as part of an Eclipse plugin project. That's probably the reason behind the configuration issues, since the same class runs smoothly as a Java application. (I even tried to set the system property "log4j.configurationFile", but the static part of LogManager gets run before the system property is recognized.)

        On the other hand, whatever the reason for reaching the else-branch in the static part of LogManager, the problem leading to the exception is the fact that SimpleLoggerContext implements an interface named LoggerContext (spi.LoggerContext) but gets cast to a class that is also named LoggerContext (core.LoggerContext) but is incompatible.

        Show
        Eric Schellhammer added a comment - I tried to use it as part of an Eclipse plugin project. That's probably the reason behind the configuration issues, since the same class runs smoothly as a Java application. (I even tried to set the system property "log4j.configurationFile", but the static part of LogManager gets run before the system property is recognized.) On the other hand, whatever the reason for reaching the else-branch in the static part of LogManager, the problem leading to the exception is the fact that SimpleLoggerContext implements an interface named LoggerContext (spi.LoggerContext) but gets cast to a class that is also named LoggerContext (core.LoggerContext) but is incompatible.
        Hide
        Ralph Goers added a comment - - edited

        Fixed in revision 1452155. Please verify and close.
        Configurator will no longer throw a ClassCastException. Instead, it will log an error and return null to the caller since Configurator must have a core LoggerContext, not a SimpleLoggerContext.

        Show
        Ralph Goers added a comment - - edited Fixed in revision 1452155. Please verify and close. Configurator will no longer throw a ClassCastException. Instead, it will log an error and return null to the caller since Configurator must have a core LoggerContext, not a SimpleLoggerContext.
        Hide
        Eric Schellhammer added a comment -

        The exception is no longer thrown, and so the immediate problem is solved.
        However, the way it is constructed now, even a valid URI parameter configLocation is effectively ignored if the default configuration fails (i.e. returns the SimpleLoggerContext). This leaves no possibility for configuration in this case, significantly reducing the features of Log4j2.

        Should this be stated as a new bug or continued in this issue?

        Btw: If I see it correctly, the SimpleLogger can never be used as a normal Logger for Log4j2, but only in the context of the StatusLogger. This may be the intended behaviour; if this is so, however, the class comment in SimpleLogger.java should be altered accordingly.

        Show
        Eric Schellhammer added a comment - The exception is no longer thrown, and so the immediate problem is solved. However, the way it is constructed now, even a valid URI parameter configLocation is effectively ignored if the default configuration fails (i.e. returns the SimpleLoggerContext). This leaves no possibility for configuration in this case, significantly reducing the features of Log4j2. Should this be stated as a new bug or continued in this issue? Btw: If I see it correctly, the SimpleLogger can never be used as a normal Logger for Log4j2, but only in the context of the StatusLogger. This may be the intended behaviour; if this is so, however, the class comment in SimpleLogger.java should be altered accordingly.

          People

          • Assignee:
            Ralph Goers
            Reporter:
            Eric Schellhammer
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development