Talk:Java Naming and Directory Interface

Latest comment: 18 years ago by 152.91.9.242 in topic User:pmurray_bigpond.com

User:pmurray_bigpond.com

edit

Might be worthwhile adding a section "What's it for"? Here's an attempt at what I have in mind:

There exist many standard java APIs for various services. At the java language level, to use these kinds of services one somehow gets a reference to an object implementing a well-known interface and then calls methods on it. Examples of these kinds of things include database connections (java.sql.Connection), places where you can emit output to (java.io.Writer).

The difficulty is in "somehow getting a reference". There are one or two problems:

  • The code should not need to know the name of the implementing class. Eg: you shouldn't need to classload the Oracle driver manager beforee you ask for a connection.
  • Different vendors may do it in different ways - factory methods vs just creating an instance
  • different APIs do it in different ways. Some use system properties to hold that name of a base factor class (eg: CORBA). JDBC does the thingy where you classload the diver class. Log4j has a system of config files accessible as resources.
  • there are issues when things are running in J2EE containers
    • the container may want to restrict access to services
    • the container might want to hot-remap resorces

JNDI provides a federated namespace, which provides a standard way of getting at any service. Any service becomes accessible by asking for a name, which is a formatted string. Further, containers can do security and remapping and whatnot by providing the JNDI context that components get. To facilitatae this, components in a J2EE container only ever ask for services in the "java:comp/<xxx>" namespace. In principle, a comtainer is free to forbid access by a component to any name outside this space. It is the containers responsibility to return an appropriate object when a name lookup is performed. This is done by vendor-specific configuration and setup. Thus, the coder of a J2EE component does not need to know anything about the environment the component will be running in: all she needs to know (or specify) is what names are available within the runtime namespace for the component, and what interface class these names return. It's someone else's job to configure the container to make those names available to the component at runtime.— Preceding unsigned comment added by 152.91.9.242 (talkcontribs) 02:17, 3 January 2006 (UTC)Reply

Versioning for JNDI

edit

Anyone know when there were any updates to JNDI? I can find no updates to the API since 2006.-jim 12:52, 4 September 2018 (UTC) — Preceding unsigned comment added by Jwilleke (talkcontribs)