Question

Naming and Directory (JNDI) - What are Pitfalls for Using JNDI

Answer 1

The question is a bit vague, but here are a few points to consider and that relates to JNDI.

the benefit of JNDI is that object creation is decoupled from object lookup
direct lookup in JDNI impede testability, prefer injection if possible
if you still use direct lookup, you will need to mock JNDI either yourself or by using a file-system implementation
beware classloader issue if you use it in app. server
the parameters used in ObjectFactory are somehow obscure if you plan to implement your own object factory (context, environment, etc.)
each JVM has its own JNDI. When a client looks up a remote EJB, a special factory is used that returns a remote reference to the EJB, but the JNDI is itself local. (Note that there exist clustered JNDI implementation but I have no experience with it).
Naming of EJBs will depend from app. server
Global and local JNDI is always a source of confusion
I ve never seen anybody searching a JNDI directory, only example of lookup

I used JDNI to implement Custom Resource in Glassfish and that was OK. But I found JNDI to be a frequent source of confusion.

Answer 2

Here is my top three:

Lacking documentation
half-hearted API
Haven t found anyone using it besides app servers

There are a couple of tutorials how to use JNDI but most of the time, you ll be stuck when something goes wrong. The implementation also frowns upon useful error messages. If a key can t be found, then you just get the innermost key name - the path which lead to the key is missing.

There is also no way to navigate the JNDI hierarchy. What s the point of having a hierarchy with parent and children when you can t navigate it?

And what about java:comp/env? Why is it there? When can I omit it? When do I have to use it? Has anyone ever added a tree which doesn t start with java:?

友情链接