Details

    • Type: Wish Wish
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-beta3
    • Component/s: API
    • Labels:
      None

      Description

      On Dec 3, 2008, at 10:22 PM, Scott Deboy wrote on log4j-dev:

      ...

      Whatever we do moving forward, I'd like to see increased support for properties. MDC and NDC are useful, but something that isn't thread specific would be useful (one reason why property rewrite policy/rewriteappender were created was to get around this limitation).

        Activity

        Hide
        Ralph Goers added a comment -

        The experimental version of Log4j 2.0 borrows from the StrSubstitutor and StrLookup in Commons Lang and Interpolator in Commons Configuration. The configuration currently supports resolving properties from the MDC, System Properties, inline in the configuration, Environment Variables and data in StructuredDataMessages. Variables of the form $

        {xxx:name}

        will be resolved by the Configuration directly while variables of the form $$

        {xxx:name}

        will be passed as $

        {xxx:name}

        to allow the underlying component to resolve them at execution time.

        Show
        Ralph Goers added a comment - The experimental version of Log4j 2.0 borrows from the StrSubstitutor and StrLookup in Commons Lang and Interpolator in Commons Configuration. The configuration currently supports resolving properties from the MDC, System Properties, inline in the configuration, Environment Variables and data in StructuredDataMessages. Variables of the form $ {xxx:name} will be resolved by the Configuration directly while variables of the form $$ {xxx:name} will be passed as $ {xxx:name} to allow the underlying component to resolve them at execution time.
        Hide
        scott deboy added a comment -

        That's great, but my intent was to ensure we more fully support arbitrary name/value pairs added to logging events, as MDC does but that is threadlocal-specific. More specifically, maybe adding some overloaded logging methods which take a Map and build event properties out of the map. There is also RewriteAppender, which for example could be used with a PropertyRewritePolicy to allow apps to add static properties added to every logging event...

        Show
        scott deboy added a comment - That's great, but my intent was to ensure we more fully support arbitrary name/value pairs added to logging events, as MDC does but that is threadlocal-specific. More specifically, maybe adding some overloaded logging methods which take a Map and build event properties out of the map. There is also RewriteAppender, which for example could be used with a PropertyRewritePolicy to allow apps to add static properties added to every logging event...
        Hide
        Ralph Goers added a comment -

        I think I need a more concrete explanation.

        Are you saying you would want to declare these properties in the configuration on an Appender that wraps other Appenders and adds them to the event the subordinate Appender sees? At least, that sounds similar to your description of the RewriteAppender. Adding an Appender that does that would be fairly simple.

        On the other hand, if you want them added to the logging methods then I would say that the Message interface is already sufficient for that. See StructuredDataMessage for an example.

        Show
        Ralph Goers added a comment - I think I need a more concrete explanation. Are you saying you would want to declare these properties in the configuration on an Appender that wraps other Appenders and adds them to the event the subordinate Appender sees? At least, that sounds similar to your description of the RewriteAppender. Adding an Appender that does that would be fairly simple. On the other hand, if you want them added to the logging methods then I would say that the Message interface is already sufficient for that. See StructuredDataMessage for an example.
        Hide
        scott deboy added a comment -

        I'm suggesting there are a number of use cases which are supported in log4j 1.2 that I think should be supported going forward, and some new ones, around the ability to add name/value pairs to logging events.

        There are a few use cases: deployment-time definition of properties, definition of properties at event generation time, and threadlocal-associated properties. There may be more.

        The example I provided was one we support today: the ability to add hostname and app name properties to all events generated by a fileappender via configuration.

        Show
        scott deboy added a comment - I'm suggesting there are a number of use cases which are supported in log4j 1.2 that I think should be supported going forward, and some new ones, around the ability to add name/value pairs to logging events. There are a few use cases: deployment-time definition of properties, definition of properties at event generation time, and threadlocal-associated properties. There may be more. The example I provided was one we support today: the ability to add hostname and app name properties to all events generated by a fileappender via configuration.
        Hide
        Kalpesh Soni added a comment -

        what about environment varialbles in log4j.xml

        e.g.

        {ENV.MYAPP_HOME}

        ?

        Show
        Kalpesh Soni added a comment - what about environment varialbles in log4j.xml e.g. {ENV.MYAPP_HOME} ?
        Hide
        Ralph Goers added a comment -

        Log4j 2.x already supports environment variables. See http://loggingtest.apache.org/log4j/2.x/manual/lookups.html#EnvironmentLookup.

        Show
        Ralph Goers added a comment - Log4j 2.x already supports environment variables. See http://loggingtest.apache.org/log4j/2.x/manual/lookups.html#EnvironmentLookup .
        Hide
        Ralph Goers added a comment -

        In addition to variable support, a PropertiesRewritePolicy has been added to provide functionality equivalent to Log4j 1.x. In addition, properties can be added to the ThreadContext Map being logged by specifying them on the Logger configuration.

        Show
        Ralph Goers added a comment - In addition to variable support, a PropertiesRewritePolicy has been added to provide functionality equivalent to Log4j 1.x. In addition, properties can be added to the ThreadContext Map being logged by specifying them on the Logger configuration.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development