Re: SLF4J instead of Log4J at the API level? [EXTERNAL]

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 u

RE: SLF4J instead of Log4J at the API level? [EXTERNAL]

Hi Sean & team, On this very topic, and related. Sean - thanks for your timely response on my previous inquiry to Java 17, everything built perfectly with 6.0.0, and with our module added-in for its inclusion with all the other 6.0.0 included modules. The code built fine, while I inherited th

RE: SLF4J instead of Log4J at the API level? [EXTERNAL]

Hi Ryan, Could you please share the report? My local build has most of the dependencies running at their latest versions, but my maven report doesn't include dependencies of dependencies so it's hard to get them all. Thanks, John -Original Message- From: Ryan Swenson Sent: Friday, Ju

Re: SLF4J instead of Log4J at the API level? [EXTERNAL]

And again on this same topic - log4j, I noticed a new inability to control the logging level of our high-volume ctakes installation and discovered that there are several jars (two 3rd-party new in 5.1.0) that contain a log4j.properties with root logging set to INFO and a console appender on root.

Re: SLF4J instead of Log4J at the API level? [EXTERNAL]

Hi, > On 26. Jul 2024, at 12:42, Peter Abramowitsch wrote: > > The log4j team themselves say that bundling property files inside > distributed jars is good practice and it took a while to track this down. > Should we officially remove them from the ctakes-core build? IMHO: Logging configuratio

Re: SLF4J instead of Log4J at the API level? [EXTERNAL]

Wow, I am really glad that these vulnerability updates have grabbed so much attention from the community! Attempting to address things in order: Ryan, please share your report on vulnerable items! We are using a couple of tools but they are definitely not uncovering so much information. I wan

Re: SLF4J instead of Log4J at the API level? [EXTERNAL]

Stated more succinctly than my babble! From: Richard Eckart de Castilho Sent: Friday, July 26, 2024 12:06 PM To: dev@ctakes.apache.org Subject: Re: SLF4J instead of Log4J at the API level? [EXTERNAL] * External Email - Caution * Hi, > On 26. Jul 2024, at 12:42

Re: SLF4J instead of Log4J at the API level? [EXTERNAL]

Hi Sean I meant to say that it wasn't good practice (woops... still jet lagged). And yes I do use the log4j bridge to log4j2 rather than reload. I'm glad that log4j1 is disappearing from cTakes. Peter On Fri, Jul 26, 2024 at 9:40 AM Finan, Sean wrote: > Wow, I am really glad that these vulnera

Re: SLF4J instead of Log4J at the API level? [EXTERNAL]

Hi Richard... It was a typo on my part. I meant to write: "wasn't" Peter On Fri, Jul 26, 2024 at 9:09 AM Richard Eckart de Castilho wrote: > Hi, > > > On 26. Jul 2024, at 12:42, Peter Abramowitsch > wrote: > > > > The log4j team themselves say that bundling property files inside > > distri

Re: SLF4J instead of Log4J at the API level? [EXTERNAL]

Hi Sean, i have set up an initial PR here: https://github.com/apache/ctakes/pull/21 However, there are a few issues: - The lifecycle plugin in the root POM uses "version" instead of "versionRange" in the main branch - the PR fixes that - The main branch still uses ContextSingletonBeanFactory

Build cTAKES using GitHub action?

Btw. how about setting up a GitHub action for building cTAKES? -- Richard