Re: SLF4J 2.x in TomEE 9.1.x and 10.0.x?
I've no issue with including it in 8.x, with respect to the EOL announcement. What I'm really asking is: if we do this update in 8.x, and you know it'll negatively impact you (i.e. you'll have some sort of regression), please say so. I'll give it a couple of days and then merge the change in, unless we hear of anything that suggests there would be an issue. Jon On Mon, Nov 20, 2023 at 12:32 PM Alex The Rocker wrote: > +1 for this change, given that there's still some time before end of > this year (=potential for some critical CVEs fixing anyway) > > Le lun. 20 nov. 2023 à 12:05, Jean-Louis Monteiro > a écrit : > > > > Based on the timing (mid-November) and the EOL end of this year, is it > > worth it? > > I'd say no. But it's up to you > > -- > > Jean-Louis Monteiro > > http://twitter.com/jlouismonteiro > > http://www.tomitribe.com > > > > > > On Mon, Nov 20, 2023 at 10:48 AM Jonathan Gallimore < > > jonathan.gallim...@gmail.com> wrote: > > > > > I make these changes to 9.x and main - is there any objection to > making the > > > change to 8.x as well? > > > > > > Thanks > > > > > > Jon > > > > > > On Wed, Oct 25, 2023 at 3:28 PM Jonathan Gallimore < > > > jonathan.gallim...@gmail.com> wrote: > > > > > > > Thanks for the feedback, and especially the pointer to the JIRA! > > > > > > > > Jon > > > > > > > > On Wed, Oct 25, 2023 at 3:26 PM Richard Zowalla > wrote: > > > > > > > >> I am ok with the change. I would just updating the related deps in > our > > > >> webapps. A backing arquillian test would be useful, I guess. > > > >> > > > >> While looking into it (related to logging & classloaders), it might > be > > > >> interesting to also have a look on [1]. > > > >> > > > >> For TomeEE 10, I would like to first have the owb4 branch on main, > > > >> though (just waiting for johnzon 2.0.0). > > > >> > > > >> Gruß > > > >> Richard > > > >> > > > >> > > > >> > > > >> [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-4242 > > > >> > > > >> > > > >> > > > >> Am Mittwoch, dem 25.10.2023 um 15:19 +0100 schrieb Jonathan > Gallimore: > > > >> > 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 > > > >> > > > > >> > 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 > > > >> > > 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 > > > >> > >
Re: SLF4J 2.x in TomEE 9.1.x and 10.0.x?
+1 for this change, given that there's still some time before end of this year (=potential for some critical CVEs fixing anyway) Le lun. 20 nov. 2023 à 12:05, Jean-Louis Monteiro a écrit : > > Based on the timing (mid-November) and the EOL end of this year, is it > worth it? > I'd say no. But it's up to you > -- > Jean-Louis Monteiro > http://twitter.com/jlouismonteiro > http://www.tomitribe.com > > > On Mon, Nov 20, 2023 at 10:48 AM Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > I make these changes to 9.x and main - is there any objection to making the > > change to 8.x as well? > > > > Thanks > > > > Jon > > > > On Wed, Oct 25, 2023 at 3:28 PM Jonathan Gallimore < > > jonathan.gallim...@gmail.com> wrote: > > > > > Thanks for the feedback, and especially the pointer to the JIRA! > > > > > > Jon > > > > > > On Wed, Oct 25, 2023 at 3:26 PM Richard Zowalla wrote: > > > > > >> I am ok with the change. I would just updating the related deps in our > > >> webapps. A backing arquillian test would be useful, I guess. > > >> > > >> While looking into it (related to logging & classloaders), it might be > > >> interesting to also have a look on [1]. > > >> > > >> For TomeEE 10, I would like to first have the owb4 branch on main, > > >> though (just waiting for johnzon 2.0.0). > > >> > > >> Gruß > > >> Richard > > >> > > >> > > >> > > >> [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-4242 > > >> > > >> > > >> > > >> Am Mittwoch, dem 25.10.2023 um 15:19 +0100 schrieb Jonathan Gallimore: > > >> > 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 > > >> > > > >> > 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 > > >> > > 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 > > >> > > > > >> >
Re: SLF4J 2.x in TomEE 9.1.x and 10.0.x?
Based on the timing (mid-November) and the EOL end of this year, is it worth it? I'd say no. But it's up to you -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com On Mon, Nov 20, 2023 at 10:48 AM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > I make these changes to 9.x and main - is there any objection to making the > change to 8.x as well? > > Thanks > > Jon > > On Wed, Oct 25, 2023 at 3:28 PM Jonathan Gallimore < > jonathan.gallim...@gmail.com> wrote: > > > Thanks for the feedback, and especially the pointer to the JIRA! > > > > Jon > > > > On Wed, Oct 25, 2023 at 3:26 PM Richard Zowalla wrote: > > > >> I am ok with the change. I would just updating the related deps in our > >> webapps. A backing arquillian test would be useful, I guess. > >> > >> While looking into it (related to logging & classloaders), it might be > >> interesting to also have a look on [1]. > >> > >> For TomeEE 10, I would like to first have the owb4 branch on main, > >> though (just waiting for johnzon 2.0.0). > >> > >> Gruß > >> Richard > >> > >> > >> > >> [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-4242 > >> > >> > >> > >> Am Mittwoch, dem 25.10.2023 um 15:19 +0100 schrieb Jonathan Gallimore: > >> > 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 > >> > > >> > 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 > >> > > 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 | exabr...@gmail.com > >> > > 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. > >> > > > >> > >> >
Re: SLF4J 2.x in TomEE 9.1.x and 10.0.x?
I make these changes to 9.x and main - is there any objection to making the change to 8.x as well? Thanks Jon On Wed, Oct 25, 2023 at 3:28 PM Jonathan Gallimore < jonathan.gallim...@gmail.com> wrote: > Thanks for the feedback, and especially the pointer to the JIRA! > > Jon > > On Wed, Oct 25, 2023 at 3:26 PM Richard Zowalla wrote: > >> I am ok with the change. I would just updating the related deps in our >> webapps. A backing arquillian test would be useful, I guess. >> >> While looking into it (related to logging & classloaders), it might be >> interesting to also have a look on [1]. >> >> For TomeEE 10, I would like to first have the owb4 branch on main, >> though (just waiting for johnzon 2.0.0). >> >> Gruß >> Richard >> >> >> >> [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-4242 >> >> >> >> Am Mittwoch, dem 25.10.2023 um 15:19 +0100 schrieb Jonathan Gallimore: >> > 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 >> > >> > 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 >> > > 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 | exabr...@gmail.com >> > > 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. >> > > >> >>
Re: SLF4J 2.x in TomEE 9.1.x and 10.0.x?
Thanks for the feedback, and especially the pointer to the JIRA! Jon On Wed, Oct 25, 2023 at 3:26 PM Richard Zowalla wrote: > I am ok with the change. I would just updating the related deps in our > webapps. A backing arquillian test would be useful, I guess. > > While looking into it (related to logging & classloaders), it might be > interesting to also have a look on [1]. > > For TomeEE 10, I would like to first have the owb4 branch on main, > though (just waiting for johnzon 2.0.0). > > Gruß > Richard > > > > [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-4242 > > > > Am Mittwoch, dem 25.10.2023 um 15:19 +0100 schrieb Jonathan Gallimore: > > 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 > > > > 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 > > > 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 | exabr...@gmail.com > > > 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. > > > > >
Re: SLF4J 2.x in TomEE 9.1.x and 10.0.x?
I am ok with the change. I would just updating the related deps in our webapps. A backing arquillian test would be useful, I guess. While looking into it (related to logging & classloaders), it might be interesting to also have a look on [1]. For TomeEE 10, I would like to first have the owb4 branch on main, though (just waiting for johnzon 2.0.0). Gruß Richard [1] https://issues.apache.org/jira/projects/TOMEE/issues/TOMEE-4242 Am Mittwoch, dem 25.10.2023 um 15:19 +0100 schrieb Jonathan Gallimore: > 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 > > 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 > > 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 | exabr...@gmail.com > > 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. > >
Re: SLF4J 2.x in TomEE 9.1.x and 10.0.x?
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 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 > 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 | exabr...@gmail.com > 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. >
Re: SLF4J 2.x in TomEE 9.1.x and 10.0.x?
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 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 | exabr...@gmail.com 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.
SLF4J 2.x in TomEE 9.1.x and 10.0.x?
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
