Well, from 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.
Anyone who knows
how to only sign and publish to Orbit without
re-bundling?
Thanks. That's really great! It would be great
for this release cycle if it were jar signed and
available from Orbit so that we could ship it with
2022-03...
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...
Regards,
Ed
On 08.02.2022 15:48, Dirk Fauth via
cross-project-issues-dev wrote:
Hi,
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
so far.
That said, re-bundling for Orbit
should not be necessary as reload4j could
directly be consumed via Maven Central.
On 26/01/2022 07:48, Christoph Läubrich wrote:
> Why not using SLF4J in all places and let
the user choose the
> implementation with their favorite CVEs?
Use of SLF4J has been suggested before and so I
tried to be a good
Eclipse citizen. My failed attempts are
described in:
If SLF4J is to be used, can someone please
ensure that the platform is
fit for purpose and that there is a good
tutorial on how to do really
boring logging.