[Configuration] includes in PropertiesConfiguration / classloader case

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Configuration] includes in PropertiesConfiguration / classloader case

Stefan Rufer
Hi,

I just started to write a few lines with the Configuration framework -
cool stuff, congrats to the authors !!

About the include-mechanism for properties files. As
far as I understood the sourcecode in PropertiesConfiguration, includes
will be disabled if no basePath is available. That's the case if
properties files get loaded by the classloader.

Is this desired behaviour? IMO it should be possible to use the include
mechanism even if files are loaded by the classloader.


thanks for advice
Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Configuration] includes in PropertiesConfiguration / classloader case

Oliver Heger
This include machanism in properties files had already existed when I
came to this project, so I don't know this code too well. Support for
loading configuration files from the classpath was added later, so this
might be the reason why there are problems.

However this whole include stuff was made a bit obsolete by
ConfigurationFactory and the possibility of defining multiple
configuration sources in a configuration definition file, which are
collected and added to a CompositeConfiguration. Wouldn't this be an
alternative for you?

Oliver

Stefan Rufer wrote:

> Hi,
>
> I just started to write a few lines with the Configuration framework -
> cool stuff, congrats to the authors !!
>
> About the include-mechanism for properties files. As far as I understood
> the sourcecode in PropertiesConfiguration, includes will be disabled if
> no basePath is available. That's the case if properties files get loaded
> by the classloader.
>
> Is this desired behaviour? IMO it should be possible to use the include
> mechanism even if files are loaded by the classloader.
>
>
> thanks for advice
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [Configuration] includes in PropertiesConfiguration / classloader case

Jörg Schaible-2
In reply to this post by Stefan Rufer
Hi Oliver,

Oliver Heger wrote on Wednesday, May 11, 2005 8:09 AM:

> This include machanism in properties files had already existed when I
> came to this project, so I don't know this code too well. Support for
> loading configuration files from the classpath was added
> later, so this
> might be the reason why there are problems.
>
> However this whole include stuff was made a bit obsolete by
> ConfigurationFactory and the possibility of defining multiple
> configuration sources in a configuration definition file, which are
> collected and added to a CompositeConfiguration. Wouldn't this be an
> alternative for you?

The general problem with the confiuguration factory is that it pulls in all the dependencies. Without it you just have JDK and commons-logging and you still can use Properties and XML. You just pay for what you need.

- Jörg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Configuration] includes in PropertiesConfiguration / classloader case

Oliver Heger
Hi J?rg,

J?rg Schaible wrote:

> Hi Oliver,
>
> Oliver Heger wrote on Wednesday, May 11, 2005 8:09 AM:
>
>
>>This include machanism in properties files had already existed when I
>>came to this project, so I don't know this code too well. Support for
>>loading configuration files from the classpath was added
>>later, so this
>>might be the reason why there are problems.
>>
>>However this whole include stuff was made a bit obsolete by
>>ConfigurationFactory and the possibility of defining multiple
>>configuration sources in a configuration definition file, which are
>>collected and added to a CompositeConfiguration. Wouldn't this be an
>>alternative for you?
>
>
> The general problem with the confiuguration factory is that it pulls in all the dependencies. Without it you just have JDK and commons-logging and you still can use Properties and XML. You just pay for what you need.
>
> - J?rg
>

I see your point. I have some plans for the future to replace the
loading mechanism of ConfigurationFactory, which is now based on
digester, by an implementation that uses XMLConfiguration instead. This
would reduce the dependencies.

I am not sure whether we still would need beanutils though for creating
and initializing objects.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Configuration] includes in PropertiesConfiguration / classloader case

Stefan Rufer
In reply to this post by Oliver Heger

On Wed, 11 May 2005, Oliver Heger wrote:
> However this whole include stuff was made a bit obsolete by
> ConfigurationFactory and the possibility of defining multiple configuration
> sources in a configuration definition file, which are collected and added to
> a CompositeConfiguration. Wouldn't this be an alternative for you?

Hmm, not quite. For a bigger development team we are setting up a JUnit
part that provides pre-configured TestCases. As different developers may
have different configs, the idea is to implement a dynamic overloading
mechanism for properties:

1st Prio  USERNAME.properties
2nd Prio  junit.properties
3rd Prio  default.properties

This is hard to do with a configuration definition file: As a user should
be able to override properties by _just_ adding it's USERNAME.properties
file, we can't foresee these entries in the config def file (don't want
all these usernames in there). Therefore we dynamically build up our
configuration inside the code using a CompositeConfiguration.

And: The include possibility is cool, I really like this, it provides
flexibility!

I had a quick look at the code but was not able to submit a patch right
now. Hope to find the time :-)


Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Configuration] includes in PropertiesConfiguration / classloader case

Oliver Heger
Stefan Rufer wrote:

>
> On Wed, 11 May 2005, Oliver Heger wrote:
>
>> However this whole include stuff was made a bit obsolete by
>> ConfigurationFactory and the possibility of defining multiple
>> configuration sources in a configuration definition file, which are
>> collected and added to a CompositeConfiguration. Wouldn't this be an
>> alternative for you?
>
>
> Hmm, not quite. For a bigger development team we are setting up a JUnit
> part that provides pre-configured TestCases. As different developers may
> have different configs, the idea is to implement a dynamic overloading
> mechanism for properties:
>
> 1st Prio  USERNAME.properties
> 2nd Prio  junit.properties
> 3rd Prio  default.properties
>
> This is hard to do with a configuration definition file: As a user
> should be able to override properties by _just_ adding it's
> USERNAME.properties file, we can't foresee these entries in the config
> def file (don't want all these usernames in there). Therefore we
> dynamically build up our configuration inside the code using a
> CompositeConfiguration.
>
> And: The include possibility is cool, I really like this, it provides
> flexibility!
>
> I had a quick look at the code but was not able to submit a patch right
> now. Hope to find the time :-)
>
>
> Stefan
>

Stefan,

if you send a patch, I will be glad to review and commit it. You are
welcome!

Here is another idea for a solution for now: ConfigurationFactory is
able to locate files in the user's home directory. So if you include an
optional configuration file, say user.properties, different files can be
loaded depending on the logged in user. Don't know if this is suitable
for your scenario.

Oliver

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Configuration] includes in PropertiesConfiguration / classloader case

Emmanuel Bourg-3
Oliver Heger wrote:

> Here is another idea for a solution for now: ConfigurationFactory is
> able to locate files in the user's home directory. So if you include an
> optional configuration file, say user.properties, different files can be
> loaded depending on the logged in user. Don't know if this is suitable
> for your scenario.

and if we interpolated the system properties in the configuration
descriptor we could have a configuration file with the name of the
current user with:

<properties fileName="${user.name}.properties"/>

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Configuration] includes in PropertiesConfiguration / classloader case

Stefan Rufer
On Wed, 11 May 2005, Emmanuel Bourg wrote:
> and if we interpolated the system properties in the configuration descriptor
> we could have a configuration file with the name of the current user with:
>
> <properties fileName="${user.name}.properties"/>

Now, that would be a very elegant solution!

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]