Log4j 2
  1. Log4j 2
  2. LOG4J2-595

Support plugin preloading through the standard javax.annotation.processing tool

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Implemented
    • Affects Version/s: 2.0-rc2
    • Fix Version/s: 2.0-rc2
    • Component/s: Core
    • Environment:

      Recent versions of Java and Maven

      Description

      Currently, in order to preload plugins, you have to add an exec-maven-plugin task to scan your code. Ideally, there'd be an annotations artifact (at least for the plugin annotations, but really just has to have all the necessary ones used for this) and a processor artifact that you'd include in your project. Then the maven-compiler-plugin would automatically run that annotation processor on your project during the compile phase. This would require less work from the end user to support their own custom plugins.

        Issue Links

          Activity

          Hide
          Matt Sicker added a comment -

          Proposed plugin annotations module. See log4j-dev mailing list for larger proposal.

          Show
          Matt Sicker added a comment - Proposed plugin annotations module. See log4j-dev mailing list for larger proposal.
          Hide
          Ralph Goers added a comment -

          A "typical" user of log4j should only need log4j-api and log4j-core and no other dependencies. I consider a typical user to be one who creates their own plugins and who may or may not preload them.

          We have added a lot of dependencies, such as the disruptor, and I am not entirely sure if they are optional or not. But adding more jars is going in the wrong direction.

          There are two ways to address this issue that I see:
          1. Create a maven plugin to replace the exec plugin.
          2. Create an annotation processor for the compiler to use. If you want to put just the annotation processor in its own jar that would be OK. We would have to tell Maven users to use provided scope to keep Maven from including it when it packages.

          Show
          Ralph Goers added a comment - A "typical" user of log4j should only need log4j-api and log4j-core and no other dependencies. I consider a typical user to be one who creates their own plugins and who may or may not preload them. We have added a lot of dependencies, such as the disruptor, and I am not entirely sure if they are optional or not. But adding more jars is going in the wrong direction. There are two ways to address this issue that I see: 1. Create a maven plugin to replace the exec plugin. 2. Create an annotation processor for the compiler to use. If you want to put just the annotation processor in its own jar that would be OK. We would have to tell Maven users to use provided scope to keep Maven from including it when it packages.
          Hide
          Matt Sicker added a comment -

          Right now I'm just including it in log4j-core so we can use it ourselves, though I'm not entirely sure if an annotation processor can be run on the same module it's in (and splitting it into its own module would introduce a circular dependency with log4j-core if the annotations weren't also split out). I'm also creating a serializable object that corresponds to a plugin entry in the .dat file for easier reading/writing.

          Show
          Matt Sicker added a comment - Right now I'm just including it in log4j-core so we can use it ourselves, though I'm not entirely sure if an annotation processor can be run on the same module it's in (and splitting it into its own module would introduce a circular dependency with log4j-core if the annotations weren't also split out). I'm also creating a serializable object that corresponds to a plugin entry in the .dat file for easier reading/writing.
          Hide
          Ralph Goers added a comment -

          The processor would have a dependency on core. That means core would just keep doing what it is doing, but other things could use it.

          I don't understand what you mean about creating a serializable object. As I recall the .dat file is just a serialized hashmap.

          Show
          Ralph Goers added a comment - The processor would have a dependency on core. That means core would just keep doing what it is doing, but other things could use it. I don't understand what you mean about creating a serializable object. As I recall the .dat file is just a serialized hashmap.
          Hide
          Matt Sicker added a comment -

          It's manually serialized. It could be automated more with an actual serializable object corresponding to the data being written and read.

          Show
          Matt Sicker added a comment - It's manually serialized. It could be automated more with an actual serializable object corresponding to the data being written and read.
          Hide
          Ralph Goers added a comment -

          OK. Is there a bug in it? Is it not performing well? Are the changes required to implement an annotation processor?

          What problem are you fixing?

          Show
          Ralph Goers added a comment - OK. Is there a bug in it? Is it not performing well? Are the changes required to implement an annotation processor? What problem are you fixing?
          Hide
          Matt Sicker added a comment -

          It doesn't matter. I just wanted something for consistency. I can't get a Class object from annotation processing, but I can get the fully qualified class name of the class (which is what is written to the file anyway). Thus, I can't use the existing PluginType class and had to create a new one for storing plugin data during the processing.

          Show
          Matt Sicker added a comment - It doesn't matter. I just wanted something for consistency. I can't get a Class object from annotation processing, but I can get the fully qualified class name of the class (which is what is written to the file anyway). Thus, I can't use the existing PluginType class and had to create a new one for storing plugin data during the processing.
          Hide
          Matt Sicker added a comment -

          Work done in commits:

          1. 1585217
          2. 1585218
          3. 1585219
          4. 1585220
          5. 1585232
          6. 1585234
          7. 1585236
          Show
          Matt Sicker added a comment - Work done in commits: 1585217 1585218 1585219 1585220 1585232 1585234 1585236
          Hide
          mck added a comment -

          A problem with this approach is that it depends at runtime on

          META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat

          For shaded jarfiles you'll end up with only one random Log4j2Plugins.dat loaded.
          see PluginManager.decode(..)

          Show
          mck added a comment - A problem with this approach is that it depends at runtime on META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat For shaded jarfiles you'll end up with only one random Log4j2Plugins.dat loaded. see PluginManager.decode(..)

            People

            • Assignee:
              Matt Sicker
              Reporter:
              Matt Sicker
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development