commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [resources][configuration] was: Re: RESEND: RE: Load message resources from DB???
Date Thu, 07 Apr 2005 16:39:41 GMT
Hi, I agree there is definitely room to mix [resources] and 
[configuration]. Actually I started working on Commons Configuration 
because I wanted a smart resource bundle for a Struts application 
supporting ${variable} interpolation and automatic reloading.

I wrote a ConfigurationMessageResources implementation but it only use 
PropertiesConfiguration. A more generic implementation could bring all 
the formats supported by [configuration] to [resources]. Imagine 
writting a resource file with a .ini file instead of a .properties file, 
it would make the file much more readable, for example:



instead of:


But I have to complete my INIConfiguration implementation first ;)

Emmanuel Bourg

James Mitchell wrote:
> Like many of the Jakarta Commons projects, Commons Resources was based, 
> in part, from the initial work done in Struts and later copied over to 
> commons with the intent to one day use that library.  This is what was 
> done for Beanutils, Digester, Validator, and more I'm sure.
> (Craig, correct me if I am wrong here)
> MessageResources (the one in Struts) was created because ResourceBundle 
> (java api) did not provide the required functionality (at the time it 
> was needed).
> I have only had a cursory look at Configuration.  From what I know of 
> it, it is a reusable library for getting configuration data into your 
> application (typically during startup).  Commons Resources is a reusable 
> library for retrieving properties pairs (locale aware) for your 
> application.  I do not know if Configuration is locale aware, but I 
> suppose Commons Resources could be extended (or changed) to use 
> Configuration.
> The database extensions I did for Resources are specific to Resources, 
> but that can be changed if enough people think we should do that.
> I can see how Resources, I18N, and Configuration could play nice 
> together in providing i18n'd messages and configuration data.
> Would there be any interest in such an animal?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message