+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
<jlmonte...@tomitribe.com> 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 <r...@apache.org> 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
> > >> > <exabr...@gmail.com>
> > >> > 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
> > >> > > <jonathan.gallim...@gmail.com> 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.
> > >> > >
> > >>
> > >>
> >

Reply via email to