Using JNDI for this is a good practice, except when it is not a good practice. So, as long as you're doing it while it's a good practice, you're okay. Just don't turn it into a bad practice.
When is it a good practice? When no other options make sense. When is it a bad practice? When there are other options that make more sense.
What is a typical scenario? In a web based application, the ServletContext is a much better scope than JNDI, in my opinion. Is this object shared by all applicaitons, or is it just used between Servlet/JSP invocations. If the object is so important, why isn't it exposed as a web service, so it can be used outside of your domain?
So, there are many options. If we had more details about your scenario, or what other options you have choses, we could probably pass more judgements on your solution.
Don't put it into the JNDI tree unless you have no other options. Back in the old days of EJB 1.x, this was a common practice of putting things there, but with Contexts, Sessions, Class variables and the goal of POJOs versus Enterprise objects, there are more common better practices, but when all else fails, then maybe think of the JNDI tree. Personally, I leave it to the container to put the objects it thinks should go in there and never put anything in JNDI, but maybe a Cache instead.
JNDI is fairly straightforward and easy to use but I think there are disadvantages to JNDI - JNDI may be a bit slower. There is need for a map lookup - No strong typing. This can lead to maintainence problems and uglier code.
0
