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: pass (hermes.apache.org: local policy)
To: commons-dev@jakarta.apache.org
Path: not-for-mail
From: "Henning P. Schmiedehausen" <hps@intermeta.de>
Newsgroups: hometree.jakarta.commons.dev
Subject: Re: [CONFIGURATION] ClassPropertiesConfiguration
Date: Tue, 7 Dec 2004 13:34:24 +0000 (UTC)
Organization: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
Lines: 63
Message-ID: <cp4bh0$p9q$2@tangens.hometree.net>
References: <cp3vfj$iv8$1@tangens.hometree.net> <41B593D8.3040708@lfjr.net>
 <cp449j$lgp$1@tangens.hometree.net> <41B59B61.9020800@lfjr.net>
 <cp47hg$n78$1@tangens.hometree.net> <41B5A7B5.8040404@lfjr.net>
Reply-To: hps@intermeta.de
NNTP-Posting-Host: forge.intermeta.de
NNTP-Posting-Date: Tue, 7 Dec 2004 13:34:24 +0000 (UTC)
User-Agent: nn/6.6.5

Emmanuel Bourg <smanux@lfjr.net> writes:

>Henning P. Schmiedehausen wrote:

>>>new PropertiesConfiguration(locator.locate("config.properties));
>> 
>> I don't like that much. Once the locator has run, it has run. Passing
>> the locator object allows the implementor to catch all the calls to
>> locate() and maybe react differently.

>I'm not sure to see the need, do you have a real use case in mind ?

An idea that popped up was the "versioning locator" mentioned in the 
reply to Oliver.

>> How about wrapping the name of the configuration file / the
>> configuration parameters into the locator object:
>> 
>> config = new PropertiesConfiguration (new FileLocator("config.properties"));
>> config = new PropertiesConfiguration (new ClassPathLocator("config.properties"));
>> 
>> config.load(new FileLocator("config.properties"));

>Hmm no because a locator is a strategy to find a resource, it doesn't 
>define a resource, this is the role of the URL.

The filename might not be part of the strategy but it is vital to
locating the ressource. :-) Does it make sense to have a strategy
without a filename / a filename without a strategy (other than
defaults)? If no, then we will have to pull a pair of "resource name"
/ "Locator object") around anyway.

>> This would simplify the method signatures. We might even be able to
>> decouple things like JDBC and JNDI:
>> 
>> config = new PropertiesConfiguration(new JDBCLocator(... jdbc params...));

>Is this really simpler than instanciating DatabaseConfiguration and 
>JNDIConfiguration ? :)

It would reduce the number of C'tors and additional methods from the
Configuration implementations.

It might also reduce the duplication of code into classes.  Having one
set of objects that define the contents of a configuration resource
(Properties, XML, whatever) and another set that defines the location
of the resource (File, Classpath, JNDI, JDBC) seemed natural to
me. Maybe just a brain fart.

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
              -- actual question from a Microsoft customer survey

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