There are two hard dependencies on the "bad" version of log4j - one from ECF which I hope can easily be resolved, and one from m2t.xpand, which cannot be resolved as m2t.xpand has had no commits in 6 years and has no CI (see Bug 578941).
my point of view the usage of reload4j is the only
backwards compatible solution. Unfortunately not for
every case, e.g. too strict version ranges. The
solution forward is of course the usage of a log
wrapper to decouple development from deployment.
Anyhow I don't
know how to add a bundle jar signed and unchanged to
Orbit. I am only aware of the re-bundling via EBR.
Doing that will cause a change in the jar structure
that causes for example logpresso to identify a CVE,
although it is fixed. Which is actually only an issue
in the detection. But that was one of the reasons why
I contacted the reload4j project to change the base to
avoid the re-bundling.
knows how to only sign and publish to Orbit without
Though I'm not sure if they would consider the
problem being fixed in 1.2.19 a fact and even if
its a fact if it would be a fact that matters...
On 08.02.2022 15:48, Dirk Fauth via
I got in contact with the
reload4j team. They changed the
Bundle-SymbolicName to org.apache.log4j and
fixed several OSGi meta data related issues in
the meanwhile. Today they published 1.2.19
which should work as a drop-in replacement in
Eclipse based applications where
Require-Bundle was used. My local tests worked
That said, re-bundling for Orbit
should not be necessary as reload4j could
directly be consumed via Maven Central.