so there is no need to update ever again. Just rebuild.
Regards
Ed Willink
On 24/02/2022 02:13, Jonah Graham
wrote:
Hi folks,
I have now checked and the EPP packages that have
org.apache.log4j now have the 1.2.19 reload4j version.
Some progress has already been made on the bugs, so with a
bit more work we can have the whole simrel free of the 1.2.15
version of log4j.
However, individual projects need to update to the newest
Orbit version and rebuild. Numerous projects still have the
1.2.15 version in their p2 repos.
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.