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
