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.