[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



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to