[naming] core has been split from resource factories

[Phil Steitz <ph...@steitz.com>]

[naming] has been split into two maven subprojects, commons-naming-core 
and commons-naming-factory.  The core package depends only on Commons 
Collections and mx4j.

Executing "maven build-all" from the top level builds both subprojects 
and "maven multiproject:site" generates a (skeletal) integrated site. 
The core package can also be built by itself by executing maven build 
from the /core subdirectory.  The multiproject:site goal will fail if 
you do not -P the old top-level src directory.

There is one lonely test included, adapted from 
o.a.geronimo.naming.java.BasicContextTest.  The test does not use the 
APIs in what will likely turn out to the natural way, but it does 
illustrate at least one way to get basic lookups to work.

I am still sorting through the code and reverse-engineering tomcat's use 
of it so that I can develop some real tests.  Any suggestions (or 
better, patches!) would be appreciated.

I have also started thinking about what makes sense in terms of loading 
naming data from XML files.  There are plenty of ways to do this, what 
requires a little thought is what exactly we want to do.  If all we want 
to do is to support loading strings as property values in naming 
contexts, that is straightforward. If, on the other hand, we want to try 
to generalize tomcat's server.xml + digester + naming to configure jndi 
resources "generically" that is much harder.  Does this even make sense? 
  What does make sense "generically"?

One more thing that I have seen requested a few times on tomcat-user is 
the idea of a "standalone" JNDI provider.  I have also been thinking 
about that.  The problem is how to handle the remoting -- not so much 
from a protocol standpoint as from a reference marshalling and container 
services standpoint.  What people seem to want, for example, is to be 
able to get JNDI Datasources from a "standalone" provider.  If we want 
to support this, we need to either handle a three-way communication 
between our client, a container and a database (not a happy prospect) or 
get into the pool management business (not likely a good idea either). 
Am I missing a simple way to meet this need?


Phil