Best Practices for JNDI naming

[rwaugh]

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

[mccaffc]

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

[nhebert]

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.

[bsiggelkow]

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

[bsiggelkow]

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.