4 Replies Latest reply on Jul 23, 2002 11:49 AM by Bill Siggelkow

    Best Practices for JNDI naming

    robert mark waugh Newbie

      Hi all:

      In extension of a previous post of mine (see the FAQ forum; this one is probably more appropriate, but oh well!) I have another best practice question for the community at large.

      It seems that you have pretty much general control over where things are placed in the JNDI resolution directory. You don't have to specify any sort of hierarchy, and you can name things in whatever way you choose.

      However this obviously doesn't seem to be a good way to do things. Much like how package naming follows a conventional best practice and file systems are laid out in a standardized way, so it seems should your JNDI names.

      What are some of your methods for choosing where to place things?

      In the past, I have done something similar to the package naming structure... and often times mirroring it for EJB components:

      /com/waughonline/services/jdbc/CatalogConnectionPool-A
      /com/waughonline/greeting/HelloWorldHome
      (class is com.waughonline.greeting.HelloWorldHome)

      How about others?

      thanks,
      robert

        • 1. Re: Best Practices for JNDI naming
          Chris McCafferty Newbie

          Hi,

          I've seen a couple of 'naming schemes' in projects for JNDI.

          One common one is to go "com/mycompany/package/structure/etc/MyBeanClass", much as you laid out. This is all well and good...until the java implementation changes to NewBeanClass. Then you are stuck with a class name/jndi name mismatch. Or you have to change the clients of that bean.

          Another one I've seen is /BeanName, which has the benefit of being a bit more readable and simpler.

          One of the more amusing things to note is that JNDI is case sensitive. This led to some of our Windows developers (unused to case sensitivity in file-like systems) capitalising the application name in JNDI, and unix programmers keeping things lower case.
          And when you're debugging a log, "Application/Bean" looks awfully similar to "application/bean"!

          • 2. Re: Best Practices for JNDI naming
            Noel Hebert Newbie

            Robert,

            It really should not matter what *you* use to define
            your JNDI namespace. What really matters is what the
            *deployment* environment uses as a namespace standard.

            If you control both, then whatever you use is right for
            you. If you don't then you must use the deployment
            environment standards. Or you could use the ENC and have
            the best of both worlds!

            What I mean is you should as a matter of best practice
            refer to your EJBs and resources (JMS queues for example)
            using the ENC or Environment Naming Context.

            This means referring to your EJB's via an alias. Then
            at deployment time, map that alias to something in
            the global JNDI namespace.

            For example if I have an EJB Foo that refers to an
            EJB Bar, then in Foo I would look up Bar using
            "java:comp/env/ejb/Bar". "java:comp/env" refers to the
            ENC which you can think of as a "private" namespace
            known only to Foo.

            At deployment time, in the case of JBoss, you can map
            "ejb/Bar" in the jboss.xml to be mapped to "x/y/z/Bar"
            or maybe "x.y.z.WhoCares" or whatever.

            The point is, you can refer to it in your code any way
            you want to!

            I use JBoss to quickly proto-type ideas, then deploy them
            into an IBM WebSphere environment. I have no control over
            the IBM namespace. Using the ENC I really don't care.

            Because at deploy time, I can take my EJBs, JMS thingys,
            JDBC thingys which I named *my way* and map them to
            "their" namespace standards and *not* change a line of
            code!

            The ENC is an under used facility which makes moving
            J2EE components between different J2EE deployment
            environments (i.e. app servers) extremely easy.

            Have a quick read of Scott Stark's chapter on
            JBoss Naming Services in the JBoss 3.0 Quick Start
            Guide for a nice introduction to the ENC. The examples
            he uses are great.

            Cheers,

            Noel.

            • 3. Re: Best Practices for JNDI naming
              Bill Siggelkow Newbie

              Use of the ENC is an excellent point. Too often I have seen code that is dependent on a global (aka absolute) JNDI name. Often this is done to "make things easier". For example, people will provide a EJBHomeFactory that is used to provide easy lookup of home interfaces. However, these implementation often rely on the absolute JNDI name.

              It is reasonable to want to provide a simplified interface for accessing EJBs -- however, such implementations should do so in a way that does not hard-wire the code to the deployment.

              Also, the actual code to perform a lookup of an EJB (or any other object in JNDI) is only a couple of lines ... in many cases, the reasons for having the factory interface is simply because the developers accessing the EJBs have not been educated on how to use JNDI ... it is as simple (almost :)as the following two lines ...

              Context ctx = new InitialContext();
              FooHome home = (FooHome) PortableRemoteObject.narrow( ctx.lookup("java:comp/env/foo"), FooHome.class);

              • 4. Re: Best Practices for JNDI naming
                Bill Siggelkow Newbie

                I would be careful about using a deep hierarchy for a JNDI name. For a package it doesn't really matter as it is not a "true" hierarchy but merely implied.
                For JNDI, however, using a name like 'com/foo/app/services/bar' means JNDI actually has to create 5 contexts. Instead, I suggest using a shorter name, but still try and maintain uniqueness.