JBossNS not thread-safe?

[sysuser1]

Just got this stack trace:

java.util.ConcurrentModificationException
 at java.util.Hashtable$Enumerator.next(Hashtable.java:980)
 at org.jnp.server.NamingServer.listBindings(NamingServer.java:354)
 at org.jnp.server.NamingServer.listBindings(NamingServer.java:374)
 at org.jnp.server.NamingServer.listBindings(NamingServer.java:374)
 at org.jnp.server.NamingServer.listBindings(NamingServer.java:374)
 at org.jnp.server.NamingServer.listBindings(NamingServer.java:374)
 at org.jnp.server.NamingServer.listBindings(NamingServer.java:374)
 at org.jnp.interfaces.NamingContext.listBindings(NamingContext.java:720)
 at org.jnp.interfaces.NamingContext.listBindings(NamingContext.java:708)
 at XXX.traverseMenuHierarchy(XXX.java:443)

and looking at the source (JBoss org.jnp.server) it seems that it doesn't lock "table" while iterating, so if something is modified in the JNDI tree it throws the above exception:

 Collection bindings = table.values();
 Collection newBindings = new Vector(bindings.size());
 Iterator enum = bindings.iterator();
 while (enum.hasNext())
 {
 ...
 }

Is this expected behaviour? Isn't JNDI access supposed to be thread-safe?

[starksm64]

No, from the javax.naming.Context javadoc:

Concurrent Access
A Context instance is not guaranteed to be synchronized against concurrent access by multiple threads. Threads that need to access a single Context instance concurrently should synchronize amongst themselves and provide the necessary locking. Multiple threads each manipulating a different Context instance need not synchronize. Note that the lookup method, when passed an empty name, will return a new Context instance representing the same naming context.

For purposes of concurrency control, a Context operation that returns a NamingEnumeration is not considered to have completed while the enumeration is still in use, or while any referrals generated by that operation are still being followed.