Mailing-List: contact directory-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List"
 <directory-dev@incubator.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <4134A816.3020707@steitz.com>
Date: Tue, 31 Aug 2004 12:32:22 -0400
From: Phil Steitz <phil@steitz.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
MIME-Version: 1.0
To: Apache Directory Developers List <directory-dev@incubator.apache.org>
Subject: Re: [naming] Inquiring about status
References: <NBBBJGEAGJAKLIDBKJOPOEECLNAB.noel@devtech.com>
 <1093933334.413419160e82a@postoffice.tpg.com.au>
In-Reply-To: <1093933334.413419160e82a@postoffice.tpg.com.au>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Brett Porter wrote:
>>What about the JNDI Configurator?  Shouldn't that also tie into naming?
> 
> 
> I think we are talking about the reverse here. XmlConfigurator is for populating
> the in memory JNDI from an XML file. I'm guessing that JNDI configurator is for
> commons-configuration to populate Java beans from a JNDI tree?
> 
> I haven't looked at commons-configuration, but there is every chance it also
> loads XML config files and could be used instead.
> 
> I think at this point it is best to see where the release takes it and let
> demand drive the functionality added.
> 
> - Brett

I agree with pretty much all comments on this thread. The code has been 
released and has a lot of good, reusable functionality.  I have not looked 
recently at the tomcat CVS, but up to a few months ago nothing significant 
had changed.  I did fix a couple of small bugs in the code ported from 
tomcat.  I agree with Brett on the XmlConfigurator and relation to 
commons-configuration. It is at conceivable that the reuse could go the 
other way as well -- i.e., we could use commons-configuration to load JNDI 
data from formats other than the tomcat-style XML that the XMLConfigurator 
supports -- but it is probably not a good idea for the dependency to go 
both ways. Adding direct support for properties files and improving the 
XMLConfigurator is proabably the best way to go.

My main problem with the code as it stands is documentation and test cases 
(almost non-existent).  Some refactoring might be in order as well. 
Certainly repackaging, since I don't think I got the core/factory split 
right.  Comments/suggestions for improvement would be greatly appreciated. 
I now have some time to spend on this, so I will get back to it.

Phil