karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Grzybek <gr.grzy...@gmail.com>
Subject [PAX-LOGGING] Log4J2 problem
Date Wed, 22 May 2019 15:21:13 GMT

(sorry for writing to two mailing lists, but I think it's important).

I've just found nasty problem.

After having lots of fun with pax-logging-service and pax-logging-logback I
wanted to clean up pax-logging-log4j2. But I found that original, already
available pax-logging-log4j2 bundle actually has Export-Package header
(pax-logging-service and pax-logging-logback don't export anything).

The strange thing was that all bundles have:

Export-Package: \

The difference is that pax-logging-log4j2 additionally has

Private-Package: \
META-INF; -split-package:=merge-first, \

So it ... took the META-INF/MANIFEST.MF from
org.apache.logging.log4j:log4j-core. It wouldn't be a problem if
pax-logging-log4j2 exported something - even single package.

Here's why

// Copy old values into new manifest, when they
// exist in the old one, but not in the new one
merge(manifest, dot.getManifest());

pax-logging-log4j2 bundle didn't have any Export-Package (as intended), so
it just inherited it from org.apache.logging.log4j:log4j-core (definitely
*not* as intended...).

This is related to https://ops4j1.jira.com/browse/PAXLOGGING-240 and the
discussion here[1].

To be honest, the only thing I think is sensible here is to stop exporting
anything from pax-logging-log4j2... Extensions should be done via fragments
or pax-logging-api's org.ops4j.pax.logging.spi interfaces (like


Grzegorz Grzybek
[1]: https://groups.google.com/forum/#!msg/ops4j/yjqOzvrKRkc/t5BXmfyoBgAJ

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message