Add BND configuration for log4j-api
#1820
Conversation
|
First of all, it is great to see you using more automation to generation better OSGi and JMPS metadata in a simpler way.
You didn't mention the exports in the initial message, but I assume In case you want to disable imports of packages that are exported by a Bundle you can append |
The
Should we disable self-imports? As far as I understand, if those imports are in place This is the complete OSGi manifest in case you find more bugs: Updated: 2023-09-28 |
Thanks for the clarification. That makes sense.
That's a good question and a topic that's a bit controversial. It actually only makes sense if there there are multiple really different provides (not only different versions of the same api-bundle) to achieve the effect you mentioned for PAX-logging. This can be problematic, if there a log4j-3 is one day (if I see it correctly you are working on this, aren't you?) and a bundle for example imports org.apache.logging.log4j.util;version="[2.20,3)" and there is
Thanks for this. That was helpful! What I noticed is that you maybe want to add the directive Otherwise in case multiple providers are present in the runtime, OSGi will wire at most one provider to the log4j.api bundle, which will then only see that one and not potential others. |
|
I'll have a look soon. Please give me some time to check and comment. |
They have a retention of |
@HannesWell, thanks I fixed that. |
Differences in the module descriptor: * `java.management` is added to the optional requires. Differences in the OSGi descriptor: * the import statement on `sun.reflect` disappears, * an import statement on `org.apache.logging.log4j.internal` appears.
|
I have merged these changes into the However please feel free to add comments to this PR if you find other bugs in the OSGi descriptors. As I already mentioned elsewhere, there are no committer of the Log4j project that current work in OSGi environments and we value the opinion of experts. |
|
Sure sure, I remember - I have this tab opened to comment at some point, but I have very tight schedule recently... |
|
The problem with OSGi headers generated into bundles' I have two things.
@Header(name = org.osgi.framework.Constants.BUNDLE_ACTIVATOR, value = "${@class}")on <_bundleannotations />or (bnd version):
I used two tags: which generates For example comparing 2.21.0 (with this #1820 merged) and 2.20.0 I got this diff: there are many other differences which are rational because you've switched from maven-bundle-plugin to bnd-maven-plugin like removal of 2.21.0 also have much more required capabilities, like: which I also support - these tell OSGi developers that Log4j uses Service Loader and it makes Log4j2 really more OSGi friendly. I can also see There are some confusing headers, like Why some packages are imported with Please play with: and see yourself ;) As a reminder - Pax Logging is quite aggressive - it re-exports Log4j2 and Logback and provides own manifests. The reason was simple (historically) - there are many logging facades available for Pax Logging:
And initially there was only one backend - Log4j1. Then Logback and then Log4j2 came. So minimal OSGi runtime could use:
And with the above config you should get a lot of functinality, appenders etc without a need to install any other bundles. I guess you could do that installing Log4j2 original bundles itself, but I work in my narrow perspective, where Karaf is the OSGi runtime and Pax Logging API + impl provides the logging functionality. Sure - not a purist-OSGi approach, but works for me for almost 10 years ;) With original Log4j2 bundles installed and other bundles requiring several facades (like Hibernate needing JBoss Logging or Tomcat requiring JULI or many other bundles requiring SLF4J) the runtime config can become more complicated... I hope my comment can be helpful (even if a bit complex and long) :) |
|
Thank You for your detailed comment.
I am quite curious why so many classes must be shaded, whereas Logback only requires replacing one class. Maybe we could integrate those changes into Log4j Core?
These requirements were added by If Service Loader Mediator is a standard component in OSGi environments and it supports the way we use
I started adding The idea behind this is: we rarely add new methods to the Log4j API. So we don't want to scare implementors by announcing "Log4j API 2.42.x is out, you need to upgrade your implementations".
I guess that these do not require Service Loader Mediator. So if I understand correctly, Pax Logging covers the needs of embedded application developers and the fact that Log4j API does not require any additional OSGi bundles (except an implementation) is not a real advantage. We should probably simplify our OSGi code and require users to use Apache SPI Fly. We can document Pax Logging as an alternative for developers that require a minimal environment.
It is very helpful, thanks. |
I can justify all shaded classes:
It's not that much and maybe some of these could be backported. But I have no strong opinion on that.
The defaults are usually safe and
This is THE SINGLE, BIGGEST OSGi thing that makes it great/bad at the same time. It's all about practice - how many times do you deal with Maven versions (per jar) and how many times you work with OSGi versions (per package). In theory these are two different worlds and this discrepancy is something to be left for developers to solve (according to OSGi designers). However in my opinion we CAN'T make these package/jar versions disjoint! A package is NOT a deployment unit (despite all these clever OSGi repository specification goals). From the point of view of developer, deployer and even security scanner, it's not that "a package at version x.y.z in a jar a.b.c is vulnerable" - CVE scanners just say that "jar a.b.c is vulnerable". Yes - it's a candidate for great discussion involving good beer. I can only say from my 10 years OSGi experience that while being great design, package versions are the biggest OSGi adoption blocker... In 2023 we can say package versions lead to the point where OSGi is nowadays...
Yes - you should treat Pax Logging (API + impl) as kind of embedded Log4j2 with deep (really) OSGi awareness. Having multiple bundles installed makes OSGi runtime much more fragile (especially when you repeatedly install/uninstall new bundles or Karaf features there). Yes - Karaf which resolves bundles on each feature installation/update was refreshing Logging bundles, so making the dependencies minimal made systems much more stable (I'm speaking from JBoss/Red Hat Fuse product based on Karaf)
From the point of view of Log4j2 itself it's a good idea, because generally, SPI Fly is the best way to handle
:) |
This PR performs the necessary changes to switch
log4j-apifrommaven-bundle-pluginand a manually writtenmodule-info.javatobnd-maven-plugin.Before
In version 2.20.0 the OSGi descriptor had these imports/exports:
The decompiled module descriptor was:
After
After this PR the OSGi imports are:
and the automatically generated module descriptor is:
Updates: removed the
static transitiverequires, which seem to work as simpletransitiverequires.