Redirect Log4J 1.x to Log 2.x

[Stwissel]

Removes flag by Whitesource vulnerability scanner

Motivation:

WhiteSource vulnerability scan flags the Log4J 1.x stream as vulnerable.

Modification:

Replaced reference to log4j with log4j-1.2-api
Ran mvn test (on a Mac) successfully

Result:

Fixes #11263

[Stwissel]

Alternate approach: #11265
Close one or both if inappropriate

[normanmaurer]

@NiteshKant @chrisvest thoughts ?

[normanmaurer]

Also /cc @trustin

[trustin]

How about this one + adding Log4J2 internal logger implementation?

[normanmaurer]

@trustin we already have one ;)

[trustin]

Haha, then +1 for just accepting this one 😅

[chrisvest]

I would think that the reason we have a log4j 1.2 integration is to support deployments that wish to use log4j 1.2 for logging, the API we use to do that is an implementation detail. I couldn't find the original CVE (oh wait, here it is), but it sounds like all versions of log4j 1.2 are vulnerable, which means the ideal solution - upgrading to a non-vulnerable version - isn't possible.

So it sounds like we are dropping log4j 1.2 support entirely (btw. log4j 1.2 was declared EOL in 2015). In that case, instead of using this bridge API, we could make Log4JLoggerFactory (which we have to keep for backwards compatibility) return the log4j2 logger instead of the 1.2 class (which is hidden so we can remove it).

[normanmaurer]

@chrisvest so like this #11265 ?

[Stwissel]

Removing libraries that have been EOL for more than half a decade sounds reasonable. Any idea how many projects downstream would get into trouble doing that?

[chrisvest]

@normanmaurer Yeah, added a comment on that one.

I don't know how much trouble it would cause for downstream to remove log4j 1.2. As far as I can tell, both solutions effectively do that, though.

[normanmaurer]

@chrisvest i think this Solution will still work for people that had put log4j 1.2 on there classpath as there are no class changes

[chrisvest]

@normanmaurer Because you'd have the real log4 1.2 on the class path at runtime instead of the bridge API? I suppose if people to it like that and make sure to not depend on the bridge. Ok.

[normanmaurer]

@chrisvest exactly.. as the our dependency is marked as optional I think this should work.

[normanmaurer]

@Stwissel can you please sign our ICLA: https://netty.io/s/icla and let me know once done ?

[Stwissel]

@normanmaurer - signed

[normanmaurer]

@Stwissel thanks a lot!