[JNDI] jakarta-commons-sandbox/naming code

[Jan Bartel <ja...@mortbay.com>]

Hi,

As Henri asked for feedback on the JNDI implementation that has been 
made available in the jakarta sandbox, so here are my quick initial 
impressions:


Nice features
+ provision for associating contexts either by Thread binding or 
Classsloader binding, although binding Contexts by Classloaders will 
probably normally be used (certainly is for webapps).

+ provision for some security via execution of privileged blocks

+ provision for read-only Contexts, and for selective granting of 
permissions for writing to Contexts (although write-protecting Contexts 
might be of limited use, considering that applications are mandatorily 
shielded from each other as part of the "java:" namespace anyway)


Not so nice features
+ Occasional poor separation of concerns eg leaking of the "java:" 
context into packages unrelated to the implementation of the "java:" 
Context (eg in org.apache.commons.naming.SelectorContext)

+ No clear delineation in the "java:" context handling of 
application-specific "comp" context. There are elegant ways to enforce 
it in the implementation of the "java:" context, which prevents calling 
code from having to explicitly deal with it

+ Plethora of ObjectFactories for resources such as MailSessions etc. 
All factories always return a new object instance when looked up, which 
whilst in the spirit of the JNDI spec, is not very efficient, as many of 
these kinds of resources are designed to be efficiently shared. Consider 
binding an factory for a mail service for a webapp - every time the 
webapp looks up the MailService, a new MailSession object will be 
created and configured, rather than creating a single MailSession object 
for the webapp which will be returned every time the webapp does a 
lookup on it. Also, the MailService ObjectFactory doesn't handle config 
of the MailSession very well at all, just hardcodes values of "smtp" and 
"localhost" for the transport and host properties.

These are just some initial comments after a cursory look through the 
code. In general, I was a bit surprised by the number of classes in 
there. Looks maybe like a little bit of factoring overkill perhaps, 
considering that the core JNDI stuff just needs to provide in-memory 
lookups and a few safe-guards on the "java:" namespace. I'm conparing it 
with the JNDI impl used in Jetty, which consists of 7 classes.


cheers,
Jan