JPMS is something to work _around_, not _with_ IMO. Gary
On Thu, Nov 2, 2023, 12:25 AM Christian Grobmeier <c...@grobmeier.de> wrote: > > > On Thu, Nov 2, 2023, at 02:12, Ralph Goers wrote: > > Christian, I was at least 3 years ahead of you on this one.This is > > Sorry I was not active for a while. Good you were here. > > > precisely why in 3.x we extracted a LOT of stuff from log4j-core into > > their own modules. > > Why not 2.x? > > > To be honest the main driver was JPMS - our goal for > > 3.x Is for log4j-core to only have a hard dependency on java.base and > > as few optional dependencies as possible. > > I understand, Jpms support was added to 2.x recently. Can we do the same > thing for 2.x? > > > So when Log4Shell hit we > > moved all the JNDI stuff out of log4j-core AND require a property to be > > set to use it even if you include the jar containing the JNDI support. > > In addition, JNDI can now only access the java protocol or no protocol. > > So yes, it is very safe now. > > In this case we need to improve our communication a lot. The main website > is still showing all cves and I didn’t find the information easily that I > just asked for. > As you mentioned, this issue is history for three years but the website > still looks like all hell is loose. > > I believe you it is safe (always did after all the countless reviews), but > people still don’t. > > With all that said splitting the repos for2.x still feels right. > > Christian > > > > > Ralph > > > >> On Nov 1, 2023, at 12:22 PM, Christian Grobmeier <grobme...@apache.org> > wrote: > >> > >> As some might know, I am writing a book and the publisher gathers a lot > of feedback. Also I talk to many people in my classrooms and also to many > pros at my clients side. > >> > >> What I hear is usually: > >> - is log4j really secure? > >> - can’t I disable certain features? > >> - are you sure you get jndi right this time? > >> > >> It always comes up why I don’t recommend some competition instead. > >> > >> We should not underestimate the impact log4shell had. Jndi was at the > epi center. Us, providing a giant jar including so much stuff with > potential security holes don’t do us a favor. > >> > >> If we think we have to maintain it, ok, but why can’t we extract it to > its own dependency? > >> > >> Btw, re your comment on -1: I do not plan to do anything against > consensus. Actually I seek consensus and try to understand better why we > still have this stuff and what we can do to improve perception . In general > I feel the atmosphere in this project has heated up more than it should. > >> > >> > >> On Wed, Nov 1, 2023, at 17:29, Matt Sicker wrote: > >>> I don’t see any reason why we shouldn’t publish the JNDI support in > its > >>> own module as we’re planning in main already. Whether we eventually > >>> split out anything from the main repo is another story, but in 3.x, > >>> JNDI, like most of the optional features, will require downloading > >>> additional dependencies to explicitly opt in to using the feature > (plus > >>> the JNDI stuff has an additional property you have to set to enable > it, > >>> so you can’t end up with JNDI integration by accident even if the > >>> dependency is available). That seems fairly safe to me, and the > >>> naysayers at that point tend to be the same people who prefer > >>> printf-logging or using C because they’re elite programmers who never > >>> make mistakes and always design things perfectly decades ahead of time. > >>> > >>>> On Nov 1, 2023, at 7:18 AM, Apache <ralph.go...@dslextreme.com> > wrote: > >>>> > >>>> > >>>> If you want separate logging config files in an EJB environment > using JNDI is pretty much required. The same would be true for any > properties needed in the configuration. > >>>> > >>>> In any case, despite Piotr saying this is a majority vote, it is not. > I will veto any attempt to remove JNDI components so one really needs to > view this vote in the light that any component receiving a -1 vote cannot > be removed as it will simply get a -1 when the PR/commit is attempted from > whomever gave the -1 vote. In other words, this is NOT a procedural vote > but a code modification vote that is taking place before the code is > modified. > >>>> > >>>> Ralph > >>>> > >>>>> On Nov 1, 2023, at 3:13 AM, Christian Grobmeier < > grobme...@apache.org> wrote: > >>>>> > >>>>> On Wed, Nov 1, 2023, at 00:01, Ralph Goers wrote: > >>>>>> There is a difference between a JEE application that only uses > servlets > >>>>>> vs one that uses EJBs. At a former employer we often used JBoss to > run > >>>>>> servlets even though we had no EJBs. In an environment with EJBs I > am > >>>>>> not sure how you can distinguish the various components from each > other > >>>>>> without JNDI. > >>>>> > >>>>> I understand that in the EJB world you would need JNDI, but I fail > to understand how your EJBs would use Log4j JNDI features? It appears to me > that while EE world needs it, the Logging world does not necessary need it > >>>>> > >>>>>> > >>>>>> Ralph > >>>>>> > >>>>>>> On Oct 31, 2023, at 3:12 PM, Volkan Yazıcı <vol...@yazi.ci> wrote: > >>>>>>> Piotr, I think it is important to differentiate what is a > requirement and > >>>>>>> what is just another way of achieving something. My employer has > several > >>>>>>> Tomcat- and JBoss-based JEE applications (using Log4j) and we > don't have a > >>>>>>> single JNDI usage I know of. > >>>>>>> I would like to hear "the functional need" that can't be done in a > JEE > >>>>>>> application without JNDI. My emphasis is important, since "using > JNDI" is > >>>>>>> not a functional need. > >>>>>>> On Tue, Oct 31, 2023 at 10:55 PM Piotr P. Karwasz < > piotr.karw...@gmail.com> > >>>>>>> wrote: > >>>>>>>> Hi Christian, > >>>>>>>> On Tue, 31 Oct 2023 at 21:57, Christian Grobmeier < > grobme...@apache.org> > >>>>>>>> wrote: > >>>>>>>>> I am surprised we still have JNDI in the code at all, but this > made me > >>>>>>>> curious: > >>>>>>>>> why do JEE users need JNDI features for logging? Why can't they > just use > >>>>>>>> the normal log mechanism? > >>>>>>>> JNDI is basically a bean container/factory that allows Java EE > >>>>>>>> applications to retrieve database connection pools, message > queues or > >>>>>>>> mail sessions (and remote code as a bonus). > >>>>>>>> For the JMS appender, JNDI is essential. > >>>>>>>> For the JDBC appender there is an alternative: DBCP2 can provide a > >>>>>>>> database connection pool via a special connection string. > >>>>>>>> The SMTP appender does not use JNDI as far as I remember. > >>>>>>>> Of course there is an alternative to JNDI also in the Java EE > world > >>>>>>>> (CDI), but it doesn't work with simple servlet containers like > Tomcat. > >>>>>>>> Piotr > >>>> >
