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


I think rebundling to provide a drop-in replacement would be good.  I suppose if there were some reason one could not or should not do that (a reason that I cannot think of), one could always create a bundle that imports all the packages and exports them all in order to create a drop-in replacement.  But that's unneeded overhead.  In any case, it would be good to have a drop-in replacement.  I could use one for Xcore and I'm sure Xtext and others could and would use one too...


On 25.01.2022 19:00, Dirk Fauth wrote:

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