Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Log4j 1.x vulnerability

To be honest by using Require-Bundle developers have taken their choice and should now be punished for it instead of some one else providing some nice workaround supporting their laziness and/or ignorance.

This whole story greatly shows why import-package is always superior to require bundle if you consume API.

Anyways I'm sure there will be enough "but the show must go on" +1 so the only valid alternative is to do it like Ed suggested, making a bundle that reexports under a given name (and might in this case should even use Require-Bundle to simply merge the class spaces).

Am 25.01.22 um 19:00 schrieb Dirk Fauth:

As Log4j 1.x also has a vulnerability and that project has reached the EOL there is no official release that could be used to fix that. It seems QOS has taken over and provides a fixed version: <>

Unfortunately this can't be used in Eclipse based products to fix the issue if plug-in developers used Require-Bundle instead of Import-Package. Reload4j doesn't specify the matching Bundle-SymbolicName.

So my question to the cross project list (as I suppose this issue could be faced by several projects), would it be possible to re-bundle the reload4j jar and change the Bundle-SymbolicName to match the old Apache version? This could then be provided via Orbit for example.

For sure the correct way to solve the problem would be that every consumer Plug-in of Log4j uses Import-Package instead of Require-Bundle. But the past can't be changed. And I am looking for a backwards compatible way that is compliant to the OSS rules.

Any idea or hint is appreciated.


cross-project-issues-dev mailing list
To unsubscribe from this list, visit

Back to the top