Re: [cross-project-issues-dev] Can SLF4J be made the official logging AP

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Christian

After reading some of the SLF4J documentation, it appears that SLF4J is not a replacement for Log4J rather it is a Facade that hides Log4j or whatever other conformant logger an application configures.

At the source code level it appears to be just necessary to change

    Logger log = Logger.getLog(MyClass.class);

to

    Logger log = LoggerFactory.getLog(MyClass.class);

(using the slf4j rather than log4j imports)

and change the Import-Package from log4j to slf4j.

Thereafter it would appear that so long as some part of the application explicitly uses log4j, slf4j will be forced to delegate to log4j regardless. Once everything uses slf4j, slf4j has a freedom to choose.

It therefore appears that ordinary application plugins can change now.

My only uncertainty is the magic configuration, for which I have only cracked the Tycho fragment initialization for Xtext application tests in the last few weeks. A new magic may be required, but the SLF4J documentation rather implies that these problems may have been considered; a bit of reflection seems to have a poke around to determine whether to use log4j. It might just work. Only real way to tell is to build an Xtext application with no log4j dependencies and see what happens.

    Regards

        Ed Willink

On 24/01/2020 08:06, Christian Dietrich wrote:

Hi,

we (Xtext) currently have no capacity to do

- the bureaucracy
- analyze impacts on logging customization points in Xtext
- analyze who else uses what logging and how that change would affect them and indirectly us

Regards
Christian

Am 23.01.20 um 15:05 schrieb Ed Willink:

Hi

If there is a conflict hazard then it already exists. Examining one of my workspaces...

Good (SLF4J) - jgit, m2e
Bad (LOG4J) - mwe, ocl, qvtd, xtend, xtext

This is complete news to me. I continue to use log4j since it avoids changing code styles that have been unchanged for many many years. Other projects probably just copy prevailing practice.

I presume changing is rather easy, and of no consequence to the exported API, since the use of log4j is by import package.

However without a commitment to change by Xtext, I would be reluctant to change any Xtext-based project.

    Regards

        Ed Willink

On 23/01/2020 13:09, Hickman, Steve (AdvTech) wrote:

Log4j 1.x reached end of life in 2015. The documentation for it now appears to have gone offline. There are some Eclipse projects (call them L1 projects) that currently use Log4j 1.x directly rather than SLF4J. That means that any projects that depend on L1 projects cannot use Log4J 2.x without risking dependency collisions from attempting to load multiple versions of Log4J.

 

SLF4J was created precisely to eliminate dependencies on specific logging implementations.

 

It is important that libraries like those that plug into Eclipse not unintentionally force a specific logging implementation on their users. Those library developers have no way of knowing – and probably no way of satisfying – all the requirements of their various sets of users.

 

Given that, it seems that Eclipse should make SLF4J the ‘official’ logging API for all Eclipse libraries.

 

 

 

 

 

Steve Hickman

Software Architect

Honeywell | Aerospace

Office: 480-236-8367

 

steve.hickman@xxxxxxxxxxxxx

https://in.honeywell.com/sites/aero/ENG/advance-tech/crew-intf/Pages/crewhome.aspx

 

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev