Log4j 2
  1. Log4j 2
  2. LOG4J2-9

log4j 2.0 should leverage existing (preferably ASF) configuration frameworks

    Details

    • Type: Wish Wish
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Configurators
    • Labels:
      None

      Description

      log4j 2.0 should avoid implementing its own configuration framework in preference to being compatible with commonly used configuration frameworks and services. Compatibility with existing log4j 1.2 configuration files might be accomplished by XSLT transforms that convert the legacy format into the equivalent with the selected configuration framework. log4j 2.0 should be readily configurable with JMX and a JMX centric design for configuration may be desirable.

        Activity

        Curt Arnold created issue -
        Hide
        Curt Arnold added a comment -

        On Jun 19, 2008, at 3:58 PM, Jess Holle wrote:

        I'd also add that as long as log4j is going to continue to support multiple LoggerRepository's per JVM the log4j JMX must fully support this.

        The lack of such a capability was the clincher for me not using the existing log4j JMX classes. There were other bugs/issues as well.

        Beyond this I also really didn't like the fact that various things that are logically data collections had each element modeled as a JMX attribute. I'm not against dynamic attributes – they make perfect sense for reflection based coverage of Appender and Layout implementations, but there were cases [whose details I forget, unfortunately], where a logical list of data was converted into a dynamic attribute set – to ill effect. I used child MBeans for such cases – which also allowed for broader/deeper configuration coverage.


        Jess Holle

        Show
        Curt Arnold added a comment - On Jun 19, 2008, at 3:58 PM, Jess Holle wrote: I'd also add that as long as log4j is going to continue to support multiple LoggerRepository's per JVM the log4j JMX must fully support this. The lack of such a capability was the clincher for me not using the existing log4j JMX classes. There were other bugs/issues as well. Beyond this I also really didn't like the fact that various things that are logically data collections had each element modeled as a JMX attribute. I'm not against dynamic attributes – they make perfect sense for reflection based coverage of Appender and Layout implementations, but there were cases [whose details I forget, unfortunately] , where a logical list of data was converted into a dynamic attribute set – to ill effect. I used child MBeans for such cases – which also allowed for broader/deeper configuration coverage. – Jess Holle
        Hide
        Ralph Goers added a comment -

        The configuration mechanism needs to be pluggable. It should allow for simple mechanisms such as using commons-digester, or more complex user written configuration. Thus some sort of SPI should be provided.

        Show
        Ralph Goers added a comment - The configuration mechanism needs to be pluggable. It should allow for simple mechanisms such as using commons-digester, or more complex user written configuration. Thus some sort of SPI should be provided.
        Hide
        Paul Smith added a comment -

        We should consider Spring as part of this configuration too. I don't have anything off the top of my head in mind here,but since Spring is such a rich configuration environment we should probably not ignore how log4j may fit into a Spring environment.

        Show
        Paul Smith added a comment - We should consider Spring as part of this configuration too. I don't have anything off the top of my head in mind here,but since Spring is such a rich configuration environment we should probably not ignore how log4j may fit into a Spring environment.
        Hide
        Ralph Goers added a comment -

        I am in favor of leveraging Spring for wiring components together. I'm less clear on whether we want to expose it through to the components that have in the past been wired in via the log4j configuration. My first reaction is that it would be OK to allow Appenders, Layouts, etc as Spring beans, but not Loggers. However, if someone has a convincing argument to why everything should be configured via Spring I'm sure I could be convinced.

        It seems to me that we need fundamental agreement on whether or not to leverage Spring before we move on.

        Show
        Ralph Goers added a comment - I am in favor of leveraging Spring for wiring components together. I'm less clear on whether we want to expose it through to the components that have in the past been wired in via the log4j configuration. My first reaction is that it would be OK to allow Appenders, Layouts, etc as Spring beans, but not Loggers. However, if someone has a convincing argument to why everything should be configured via Spring I'm sure I could be convinced. It seems to me that we need fundamental agreement on whether or not to leverage Spring before we move on.
        Hide
        Paul Smith added a comment -

        Just to clear up what I actually meant, I wasn't actually advocating the use of Spring within log4j, but given how useful and popular Spring is, we should at least factor into the design something that is IoC friendly.

        for example, perhaps so 'spring-extras' companion that obey the Spring Lifecycle interface to startup/shutdown.

        The more difficult objective though for a logging framework is to then support the container in it's startup routine by allowing useful logging. Bit of a chicken/egg problem there unless the log4j configuration can be done as early as possible.

        Anyway, I was just voicing that we should probably have a Spring-like container in mind during the configuration design. May even be worth reaching out into the, say, Spring community for further discussion (or bringing them into this one)

        Show
        Paul Smith added a comment - Just to clear up what I actually meant, I wasn't actually advocating the use of Spring within log4j, but given how useful and popular Spring is, we should at least factor into the design something that is IoC friendly. for example, perhaps so 'spring-extras' companion that obey the Spring Lifecycle interface to startup/shutdown. The more difficult objective though for a logging framework is to then support the container in it's startup routine by allowing useful logging. Bit of a chicken/egg problem there unless the log4j configuration can be done as early as possible. Anyway, I was just voicing that we should probably have a Spring-like container in mind during the configuration design. May even be worth reaching out into the, say, Spring community for further discussion (or bringing them into this one)
        Hide
        Ralph Goers added a comment -

        In my experimental branch the configuration is pluggable. I investigated using other frameworks but adding a dependency really isn't worth the cost (and risk that the framework will somehow create a circularity problem). In the end the configuration I implemented is extremely simple.

        Show
        Ralph Goers added a comment - In my experimental branch the configuration is pluggable. I investigated using other frameworks but adding a dependency really isn't worth the cost (and risk that the framework will somehow create a circularity problem). In the end the configuration I implemented is extremely simple.
        Hide
        Ralph Goers added a comment -

        Closing since the Configuration aspect is pretty solid.

        Show
        Ralph Goers added a comment - Closing since the Configuration aspect is pretty solid.
        Ralph Goers made changes -
        Field Original Value New Value
        Status Open [ 1 ] Closed [ 6 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Curt Arnold
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development