Patch upgrading Xtext dependency on Log4j 1 to Log4j 2.

[eposse]

I have created patches for Xtext 2.31 upgrading Log4j 1 to Log4j 2, as discussed in the Xtext Eclipse forum, and I would like to contribute these if the Xtext team is interested. If so, I can open a pull request.

The reasons are discussed in the forum linked above.

[szarnekow]

To make this discussion self-contained, can you please summarize the arguments here? It's not obvious that the Eclipse forum will be around in some future.

Other than that: Frankly, I'm concerned about the hinted change for some reasons:

• replacing all loggers in Xtext is unlikely doable without fallout for existing clients
• log4j2 would not be the most sustainable choice - I'd rather do slf4j to bridge to "all" the different logging frameworks
• rolling out such a change because a single user isn't willing to assess the factual dependencies carefully is not compelling either - OSGI does explicitly allow to exchange java packages with other implementations. So reload4j should be a valid choice that passes all sorts of cve scanners.

So getting back to the initial question: Please add more information here.

[eposse]

Hi. Sure, here's a summary:

1. Xtext still depends on log4j1
2. log4j1 reached end-of-life in 2015
3. Many projects depend on Xtext and therefore, transitively on log4j1
4. Some organizations and companies have very stringent security requirements and reject products that include or depend on log4j1
5. log4j1 may not be vulnerable to the Log4Shell vulnerability but it does have other vulnerabilities
6. Apache provides a migration guide; see Migration from Log4j 1.x to 2.x
7. One of the simplest options it to use the "log4j 1.x bridge", but some organizations will reject it because the jar is called "log4j-1.2-api" which suggests that log4j1 is still bundled. (Yes, it's blind bureaucracy, but with certain organizations you have to comply regardless.)
8. Upgrading from log4j1 to log4j2 is not the only option, and may not be the best or most sustainable, but it is likely one of the most straight-forward, and the one with the least fallout, and it doesn't have to be the final one. It could be an intermediate step towards a better option.
9. One possible better option is slf4j.
10. The patches I have made don't use slf4j but log4j2. (I'll admit, not an ideal decision, but when I started, I wasn't aware of slf4j)
11. There is a log4j2-to-slf4j adapter: see this link

To clarify something, I am not requesting such patch to be made. I have already patched 32 Xtext bundles (and most of Xtend 1 and 2 and Xpand). And I believe that patching the rest is quite doable.

Also, keep in mind that I'm not asking the Xtext team to do this one change for us, for one customer. We already have our own Xtext fork and build from that, so we are good, and we don't need Xtext to include these patches, but we would like to be able to benefit from future Xtext improvements, and to contribute to the community, as we know we are definitely not the only ones that have encountered this sort of problem.

I do like the slf4j option, and I am not familiar with reload4j, I've just taken a very quick look. If it would allow us to make sure that there are not references to log4j1 in manifest files or feature dependencies or pom files, and that log4j1 is completely absent from a build when we declare a dependency on Xtext (or Xtend), than I'm all for it. I would appreciate help or pointers on where to get help on how to do that.

But in any case, the point is that I'm offering a set of patches that are already done (and I could try to finish the rest), and that could be used maybe as a stepping stone towards replacing the dependency on the ancient log4j1 for a better one. So, if you would like so, I could open a Pull Request and you can decide whether to continue.

[imhotep82]

We have another problem in a project: If we use a StandaloneSetup on an URL classpath that only bundles log4j2 (spring-boot), then we cannot run Xtext because the field org.eclipse.xtext.service.AbstractGenericModule.LOGGER uses log4j2. imo we should at least replace this logger with slf4j.