commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Heger (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CONFIGURATION-215) Using relative URLs
Date Thu, 15 Jun 2006 17:37:31 GMT
     [ http://issues.apache.org/jira/browse/CONFIGURATION-215?page=all ]

Oliver Heger updated CONFIGURATION-215:
---------------------------------------

    Priority: Minor  (was: Major)

Solution (1) would be hard to implement for some of the composite configuration classes. I
am not sure whether this effort is worth the value it gains because finding out from which
configuration source a certain property was loaded does not seem to me to be such a typical
use case - but I may be wrong.

Solution (3) is too specific for my taste.

Solution (2) would be my favorite because of the additional flexibility it provides. For this
request that would mean introducing a predefined variable called ${config_url} or whatever
that is replaced by the URL from which the configuration file was loaded. However for composite
configurations there is still the problem how this variable should be resolved. This would
require knowledge from which source the property was loaded (same as (1)) and also extending
the variable substitution algorithm to take the property, in which the variable is placed,
into account.

Could you live with the following simpler approach: Configurations stored in a composite configuration
can be accessed either by a numeric index or (in the case of CombinedConfiguration) by a name.
So a composite configuration could provide a family of meta variables of the form ${config_url.0},
${config_url.1}, or ${config_url_name}, which will be replaced by the URL of the corresponding
configuration source. Then it is in the responsibility of the developer to choose the correct
variable.

> Using relative URLs
> -------------------
>
>          Key: CONFIGURATION-215
>          URL: http://issues.apache.org/jira/browse/CONFIGURATION-215
>      Project: Commons Configuration
>         Type: Improvement

>     Reporter: Michiel Kalkman
>     Priority: Minor

>
> It would be useful to be able to specify URLs in configuration item values that are relative
to the configuration.
> A sample. I have the following files.
> A/config.xml   which refers to    
> B/specificConfigForB.xml   which refers to
> B/somefile
> Now specifying the location of somefile in specificConfigForB.xml should be possible
using a relative URL, such that it is possible to retrieve the absolute URL of somefile through:
> a) the absolute URL of A/config.xml (e.g.: file:/c:/A/config.xml or http://A/config.xml)
> b) the relative URL of somefile specified in B/specificConfigForB.xml (like <somefile>somefile</somefile>)
> (1) One solution is to make it possible to find the location of the configuration file
that specifies the relative URL. Or more general, commons config should know where a given
configuration item is stored.
> In this case it might be an idea to implement a getURL() on the Configuration interface
which uses:
> 1. the absolute URL of the composite configuration file, (A/config.xml)
> 2. the relative URL to the specfying configuration file, (B/specificConfigForB.xml)
> 3. the relative URL specified (in B/specificConfigForB.xml)
> (2) Another solution is to specify a special meta variable (like ${url}) that can be
used to specify the location of the specifying configuration file wrt the composite configuration
file. E.g. <somefile>${url}/somefile</somefile> would result in ../B/somefile.
> (3) Another solution would be to specify a special attribute to indicate that the value
specified is an URL. Like <somefile type="URL">somefile</somefile>.
> The advantage of solution (1) is that no extra semantics are introduced to the configuration
files. Furthermore, it might possibly be useful in debugging situations. The advantages of
solution (2) is that in this manner other meta variables might be introduced. The disadvantage
of solution (3) is that this one cannot be applied to property files.
> See also http://mail-archives.apache.org/mod_mbox/jakarta-commons-user/200606.mbox/%3c448AE9A8.2030003@oliver-heger.de%3e

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


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


Mime
View raw message