Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
To: commons-dev@jakarta.apache.org
From: Costin Manolache <cmanolache@yahoo.com>
Subject: Re: VFS and JNDI
Date: Wed, 26 Feb 2003 10:23:28 -0800
Lines: 53
Message-ID: <b3j1g4$ui0$1@main.gmane.org>
References: <b3invd$cqi$1@main.gmane.org>
 <Pine.LNX.4.33.0302261059470.26660-100000@umbongo.flamefew.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
User-Agent: KNode/0.7.2
Sender: news <news@main.gmane.org>

Henri Yandell wrote:

> 
> 
> On Wed, 26 Feb 2003, Costin Manolache wrote:
> 
>> James Strachan wrote:
>>
>> > From: "Costin Manolache" <cmanolache@yahoo.com>
>> >
>> > It'd me nice to move the Tomcat JNDI implementation into Commons so it
>> > can be a general purpose JNDI implementation for those that want/need
>> > one.
>>
>> +1 - if someone has the time :-)
>>
>> It is pretty well separated - but there are few things that are specific
>> to tomcat ( caching is specific to resources, etc). I started a small
>> refactoring - with the goal of making it completely separate in
>> jakarta-tomcat-connectrs/naming. A second goal was to make it much easier
>> to write plugins. It is pretty low on the priority list for me - but if
>> other people are interested I can make some time to help.
> 
> I'm happy to work/help on this. I've another little crappy jndi project
> and James has hassled me about doing the right thing and refactoring
> tomcat-jndi before.

The nice thing about JNDI is that the API and the provider API are as stable
as it can get, and it proved to allow very low coupling. 

In other words - there is no need for an "all or nothing" or dependencies, 
it can be done step by step. 

I already started a refactoring in j-t-c ( I'll commit today the latest
changes ), my main focus was on having some base classes that make it much
easier to implement drivers. I choose Name over String because I feel it can
be made more efficient and may support recycling and MessageBytes-based
implementation. I think it would be nice to have another set of base
classes based on Strings - duplication is good :-)

One big issue is refactoring the cache - right now it is very specific to
the tomcat use-case, and to the filesystem provider ( casts, etc ). 


Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org