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>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <41B59B61.9020800@lfjr.net>
Date: Tue, 07 Dec 2004 13:00:33 +0100
From: Emmanuel Bourg <smanux@lfjr.net>
User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [CONFIGURATION] ClassPropertiesConfiguration
References: <cp3vfj$iv8$1@tangens.hometree.net> <41B593D8.3040708@lfjr.net>
 <cp449j$lgp$1@tangens.hometree.net>
In-Reply-To: <cp449j$lgp$1@tangens.hometree.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Henning P. Schmiedehausen wrote:
> I don't think, this is overengineered. Are you sure about URL locate?
> I'd probably go for InputStream locate().

Is that for classloaders that do no support getRessource ? We really 
need to know where the file is located in order to reload it efficiently.

> Hm. I probably would like this solution better than the current (which
> reminds me of the way that commons-logging tries to find its log
> APIs). We could use current as the default and make the others
> pluggable. (and add a few C'tors which accept a Locator object)

We could either keep the current constructors and use the Locator directly :

new PropertiesConfiguration(locator.locate("config.properties));

or add one constructor :

new PropertiesConfiguration("config.properties", locator);

in this case we'll also need another load method :

config.load("config.properties", locator);


I think I prefer starting with the first solution.

Emmanuel Bourg

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