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 >>
