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 >
