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.