I’m not sure how much people use this deployment model anymore, but JNDI was and still is at the core of JavaEE (now JakartaEE) dependency injection APIs. While CDI is the current way of using dependency injection there, CDI is compatible with JNDI and the other JavaEE tech that came in between (the resource loader API thing). Typically, a JavaEE application server (think like JBoss/Wildfly, WebSphere, Weblogic, etc.) would be configured with shared resources like database and JMS connection pools, and those would be obtainable via JNDI. A single application server could host multiple servlets or more advanced packaging formats. All this JNDI usage, however, relies on the Java provider, not the LDAP or DNS or similar providers, so it works without networking being involved.
Do note, though, that there are ways to use this same tech without JNDI, but that typically involves being part of some JavaEE lifecycle, using CDI for dependency injection, etc. > On Oct 31, 2023, at 3:57 PM, Christian Grobmeier <grobme...@apache.org> wrote: > > Hi, > > on the recent deprecation vote I saw this vote (from Ralph): > >> * JNDI-related features: > -1 Unfortunately, JEE users require this. > > 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? > > To me, JNDI is a burned word in Logging. No matter what we say about it, > nobody will ever believe we will have this under control. > > I am a strong +1 on removing this, even for 2.x. Users can have a separate > module they can add to their pom, if they really need it. I am aware of > versioning and this could be considered a breaking change, but after all, the > APIs are intact, and only the pom changes. > > That being said, I would like to understand better what "jndi related" > features in our code base are actually solving, because from marketing > perspective, they are super GAU. > > Kind regards, > Christian
