Hi Richard, I have thought of that, and almost did as much. I think that main pom still has a bunch of slf4j dependencies commented out from my time in the sandbox. There are only some very minor reasons that I didn't, one being the ease of the transition. I have nothing against slf4j, and using an abstraction layer does make a lot of sense. Would you be willing to do some refactoring? I have to move over and work on some other items today - mainly ctakes on apache beam (plus spark, flink ...). Something for the next 'new features' release.
Sean ________________________________ From: Richard Eckart de Castilho <r...@apache.org> Sent: Thursday, July 25, 2024 8:40 PM To: dev@ctakes.apache.org <dev@ctakes.apache.org> Subject: SLF4J instead of Log4J at the API level? [EXTERNAL] * External Email - Caution * Hi Sean, > On 25. Jul 2024, at 16:15, seanfi...@apache.org wrote: > > The following commit(s) were added to refs/heads/main by this push: > new 1556d13 Replaced all logging with log4j2 , including java and > commons-logging Removed or pushed back a few dependencies. If I saw it correctly, you are making direct calls to the log4j2 API. Have you considered using SLF4J 2.x as your API and log4j2 as the logging backend instead? If would facilitate embedding cTAKES in contexts that use a different logging backend than log4j2. Cheers, -- Richard
