Log4j 2
  1. Log4j 2
  2. LOG4J2-19

Provide looser coupling of PatternConverters

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-alpha1
    • Component/s: Layouts
    • Labels:
      None

      Description

      Currently, PatternLayout calls PatternParser which knows about the various PatternConverters, many of which are imbedded in it. This makes it difficult for users to add their own Converters.
      In the logging framework I created each converter identified the conversion characters it supported. Each PatternConverter was required to supply a getKeys() method that returned this list. The equivalent of the PatternLayout contained an array of PatternConverters. During initialization each of these would be called and the list of keys recorded along with the associated converter. To add your own converter all that was necessary was to extend the class and add your new keys to the list of recorded keys along with their converters. The base PatternLayout would then take care of calling the correct converters as necessary.

        Activity

        Ralph Goers made changes -
        Field Original Value New Value
        Status Open [ 1 ] Closed [ 6 ]
        Assignee Ralph Goers [ ralph.goers@dslextreme.com ]
        Fix Version/s 2.0-alpha1 [ 12320347 ]
        Resolution Fixed [ 1 ]
        Hide
        Ralph Goers added a comment -

        Log4j 2's plugin mechanism solves this.

        Show
        Ralph Goers added a comment - Log4j 2's plugin mechanism solves this.
        Hide
        Ralph Goers added a comment -

        In my experimental branch I used plugins to accomplish this. A converter provides to annotations, one to declare it as a converter plugin and one to identify the keys that it matches on.

        Show
        Ralph Goers added a comment - In my experimental branch I used plugins to accomplish this. A converter provides to annotations, one to declare it as a converter plugin and one to identify the keys that it matches on.
        Hide
        Curt Arnold added a comment -

        The pattern parsing is a specialized form of configuration and should be consistent with the overall approach to configuration, with support for the pattern syntax being a specialized configurator.

        Instead of getKeys(), it sounds like the default mapping of keys to classes could be done with class attributes.

        Show
        Curt Arnold added a comment - The pattern parsing is a specialized form of configuration and should be consistent with the overall approach to configuration, with support for the pattern syntax being a specialized configurator. Instead of getKeys(), it sounds like the default mapping of keys to classes could be done with class attributes.
        Hide
        Ralph Goers added a comment -

        If it is agreed that a container such as Spring should be used then the wiring of PatternConverters should take advantage of that. Thus users would only need to add the configuration of their converter.

        Show
        Ralph Goers added a comment - If it is agreed that a container such as Spring should be used then the wiring of PatternConverters should take advantage of that. Thus users would only need to add the configuration of their converter.
        Ralph Goers created issue -

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development