I'm hoping the URLClassLoaderFirst change would mean that the slf4j-api 1.7.x could keep working for you. I'd be happy to add an Arquillian test to check that as part of a PR for the change. Does that sound ok?
The upstream dependencies are not pulling in logback. If someone wanted to use logback with SLF4J, in a Jakarta EE version of TomEE, by bundling both slf4j-api and logback in their application, they'd have to use slf4j-api 2.x (because the Jakarta EE version of logback requires that API level). Cheers, Jon On Wed, Oct 25, 2023 at 3:06 PM Jonathan S. Fisher <[email protected]> wrote: > While we use slf4j-api 1.7.x, I'm totally ok with a 2.x upgrade, > although it'd be best if the dependency wasn't seen by the apps > somehow. I know that's a lot of classloader acrobatics :) > > Just to clarify though, the upstream dependencies are or are not > including logback? If they are including logback, that transitive > dependency ought to be blocked... it's up to the final developer to > decide which binding implementation to use. Including a binding (over > the default sysout binding) would likely cause problems for users. > > > On Wed, Oct 25, 2023 at 8:58 AM Jonathan Gallimore > <[email protected]> wrote: > > > > Hi All > > > > There's a couple of suggestions I'd like to run past the group to see if > > there's any thoughts / potential issues. > > > > The first is: updating to SLF4J 2.x API and JUL implementation > > (specifically 2.0.9) in TomEE. There's a couple of rationale here: > > > > - The 1.x branch of SLF4J is no longer maintained > > - At least one of the bindings (Logback) requires a SLF4J 2.x API for > > Jakarta EE support > > > > Secondly, thanks to this bit of code in the class loader: > > > https://github.com/apache/tomee/blob/main/container/openejb-core/src/main/java/org/apache/openejb/util/classloader/URLClassLoaderFirst.java#L600-L619 > , > > it is possible for a webapp to include its own SLF4J API and binding in > its > > WEB-INF/lib to use its own logging config. With SLF4J 2.x, > > org/slf4j/impl/StaticLoggerBinder.class is not included with the binders, > > nor is it called, so shouldSkipSlf4j() returns true, even when SLF4J and > a > > binder is present in the web app. Simply removing this method, and the > > single place it is called seems to enable the web app to do its own > logging > > with its own binder. > > > > I've run a TCK build with both of these changes present, and it looks ok. > > Does anyone have any feedback with respect to these proposals? Is anyone > > out there using SLF4J in their applications with these versions of TomEE > > who would be impacted? > > > > Thanks > > > > Jon > > > > -- > Jonathan | [email protected] > Pessimists, see a jar as half empty. Optimists, in contrast, see it as > half full. > Engineers, of course, understand the glass is twice as big as it needs to > be. >
