[ 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/[EMAIL
> PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
