Eclipse Community Forums: TMF (Xtext) » Log4j 1.x updates to Log4j2

Home » Modeling » TMF (Xtext) » Log4j 1.x updates to Log4j2

Log4j 1.x updates to Log4j2 [message #1849049]

Thu, 30 December 2021 14:27

Eclipse User

The latest version of xtext is still using log4j 1.x, which is out of date and has vulnerability. Is it possible to move up the version to log4j2 or exclude it.

Re: Log4j 1.x updates to Log4j2 [message #1849053 is a reply to message #1849049]

Fri, 31 December 2021 00:26

Eclipse User

https://github.com/eclipse/xtext-core/issues/1363

Re: Log4j 1.x updates to Log4j2 [message #1849054 is a reply to message #1849053]

Fri, 31 December 2021 00:51

Eclipse User

Hi

Pretty much the whole of Eclipse uses Log4J 1.2.15 in a safe and trivial fashion. Moving before the the platform and EMF seems like a needless risk.

Regards

Ed Willink

Re: Log4j 1.x updates to Log4j2 [message #1849055 is a reply to message #1849054]

Fri, 31 December 2021 03:27

Eclipse User

The platform does not use log4j. EMF uses log4j only in the Xcore UI components and all those could simply be removed (replaced with something that doesn't use a library) except where Xtext generates the use of it, e.g., org.eclipse.emf.ecore.xcore.ui.internal.XcoreActivator.logger.. So Xtext really does need to address this before EMF does and I see no risk in any case; the logger is not exposed in any APIS.

Re: Log4j 1.x updates to Log4j2 [message #1849060 is a reply to message #1849055]

Fri, 31 December 2021 09:22

Eclipse User

Hi

The Plugin Dependencies View claims that many EMF UI plugins such edit.ui, codegen.core.ui require log4j.

However when I look closer it seems that the org.eclipse.xtext.logging fragment creates a loop that makes the display thoroughly untrustworthy.

IIRC when we moved to 1.2.15 there was considerable pain as one or two projects were distinctly tardy in responding to the responsibilities of simultaneous participation. I fear that a major change will again incur pain for very little obvious benefit. Presumably any project that exploits Xtext such as OCL or Papyrus will find that they have a conflict until all dependencies are compatible. If Xtext is to move, it should happen ASAP to maximize the opportunities for tardy projects to respond.

Regards

Ed Willink

Previous Topic:	Handling of backslash
Next Topic:	Validator context based

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 26 21:48:16 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter