[2.2.x] Warn message for package scanning deprecation from pax-logging-api

[HeshanSudarshana]

Hi,

We are currently using pax-logging version 2.1.0 currently and trying to migrate to the latest 2.2.7 version.

When trying to start the server I'm getting the following warning multiple times.

org.ops4j.pax.logging.pax-logging-api [log4j2] WARN : The use of package scanning to locate plugins is deprecated and will be removed in a future release

Further debugging the issue I identified that this is yielding from the line [1] in log4j-core version 2.22.1. This seems to be due to the following packages added from the PluginManager the pax-logging-log4j2 component [2].

Therefore, even there are no packages from our side, the warning messages are logged. Is there a way to work around this or am I missing something?

[1] https://github.com/apache/logging-log4j2/blob/rel/2.22.1/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/util/PluginManager.java#L128
[2] https://github.com/ops4j/org.ops4j.pax.logging/blob/logging-2.2.7/pax-logging-log4j2/src/main/java/org/ops4j/pax/logging/log4j2/internal/PaxLoggingServiceImpl.java#L79

Thanks in advance!

[grgrzybek]

Thanks for the issue @HeshanSudarshana. #521 was created to prepare for next major Log4j release (3.0) and till then we'll be keeping Pax Logging 2.2.x compatible with Log4j2 2.x. This means upgrading to newer 2.22.0, 2.22.1, ..., etc. releases, but such warnings may appear unfortunately.

There's no way to quite down this message because I don't think we should change the way Pax Logging itself adds its plugin to Log4j2...

So please understand - we'll check this issue at next Pax Logging release (2.3.x).

[HeshanSudarshana]

Thanks for the response @grgrzybek, I understand that these kind of issues can occur when upgrading to the latest versions.

However, shouldn't the changes be done to avoid the usages of deprecated methods such as PluginManager.addPackages in a 2.2.x patch version as well?

[grgrzybek]

deprecation in 2.22.x doesn't mean it'd be removed in any next 2.x (I hope). Anyway - I'm keeping the issue open, so I may review it and think about it. But to be honest I'm quite busy now with completely different issues (React...)

[grgrzybek]

Whew, I have a solution - instead of simple call to (now deprecated) org.apache.logging.log4j.core.config.plugins.util.PluginManager.addPackage(), I've created Pax Logging's own Maven plugin that can be configured like this:

<plugin>
    <groupId>org.ops4j.pax.logging</groupId>
    <artifactId>pax-logging-log4j2-maven-plugin</artifactId>
    <executions>
        <execution>
            <id>generate-pax-logging-log4j2-plugin-descriptor</id>
            <phase>prepare-package</phase>
            <goals>
                <goal>generate-log4j-plugin-descriptor</goal>
            </goals>
            <configuration>
                <plugins>
                    <!-- These are equivalents of deprecated org.apache.logging.log4j.core.config.plugins.util.PluginManager.addPackage() call -->
                    <plugin>org.ops4j.pax.logging.log4j2.internal.bridges.PaxOsgiAppender</plugin>
                    <plugin>org.apache.logging.log4j.layout.template.json.JsonTemplateLayout</plugin>
                    <plugin>org.apache.logging.log4j.layout.template.json.resolver.LoggerResolverFactory</plugin>
                    <plugin>org.apache.logging.log4j.layout.template.json.util.RecyclerFactoryConverter</plugin>
                </plugins>
            </configuration>
        </execution>
    </executions>
</plugin>

This is kind of equivalent of what was done in a static block of org.ops4j.pax.logging.log4j2.internal.PaxLoggingServiceImpl class:

PluginManager.addPackage(PaxOsgiAppender.class.getPackage().getName());
PluginManager.addPackage(JsonTemplateLayout.class.getPackage().getName());
PluginManager.addPackage(LoggerResolverFactory.class.getPackage().getName());
PluginManager.addPackage(RecyclerFactoryConverter.class.getPackage().getName());

This plugin generates proper Log4j2Plugins.dat file for the above plugins' packages and puts them into special location: /META-INF/pax-logging-log4j-plugins/META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat.
Log4j2 uses standard java.lang.ClassLoader#getResources() but it usually doesn't work as expected in OSGi. That's why this location is added to pax-logging-log4j2 bundle's Bundle-ClassPath manifest entry:

Bundle-ClassPath: .,META-INF/pax-logging-log4j-plugins

This ensures that one bundle (with two cp entries) can provide two URLs of the location of named /META-INF/org/apache/logging/log4j/core/config/plugins/Log4j2Plugins.dat resource. And both core and Pax Logging Log4j2 plugins are loaded this way without problems.