commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <heg...@med.uni-marburg.de>
Subject Re: [configuration] Concerns with ConfigurationRuntimeException
Date Fri, 22 Oct 2004 06:05:57 GMT
A possible solution would be to strictly separate between loading a 
Configuration and accessing its properties. So when a Configuration 
object is created all available properties are loaded into memory. This 
could cause a checked exception to be thrown. After that, access to 
properties won't cause any problems.

On a first glance, such an approach has some disadvantages: It might 
limit us when implementing new kinds of configuration sources, and 
memory usage will be high for large configuration sources. But is this 
really problematic? Here are some thoughts about this:

- When loading a Configuration it would be possible to define some 
filters so that only a subset of the available properties would be 
loaded. This would reduce memory usage. E.g. in JNDIConfiguration a 
prefix can be defined. I think a similar mechanism could be implemented 
for DatabaseConfiguration.

- I assume that nearly all available configuration properties will be 
accessed at least once during the lifetime of a client application 
(otherwise it wouldn't make sense to define them). If each property 
access caused a load operation (e.g. from a database), this could cause 
a performance issue. So for N properties this would result in at least N 
load operations instead of one for loading all (or a subset) properties 
at creation time.

- For configuration implementations that do not keep their properties in 
memory iteration over the available keys using the getKeys() method 
might be problematic and expensive because it may result in loading the 
whole data. ConfigurationFactory makes use of the getKeys() method at 
least for creating union configurations. So one could argue that in this 
scenario all properties are loaded anyway.

Regards
Oliver

Eric Pugh wrote:
> I think both arguments are valid.  It depends on your use case.   One of the
> obstacles with an interface like Configuration is that you don't know who is
> going to implement it.  And some are reliable, and some are not.  For the
> same reasons that the Map,Set,List interface don't throw checked exceptions,
> so Configuration doesn't throw.  Especially since I think that the most
> common use would be:
> 
> try {
> conf.getString("hi");
> }
> catch (ConfigurationException ce){
> throw new RuntimeException(ce)
> }
> 
> and so on..  It most apps the graceful shutdown aspects are never
> implemented.  ON a webapp I often just bubble the error up and say "try
> again"..   However, there are apps, like a public facing app, where you
> can't do that.
> 
> Could we have two interfaces?  Configuration and StrictConfiguration?
> StrictConfiguration would declare checked methods?
> 
> Eric
> 
> 
>>-----Original Message-----
>>From: Ricardo Gladwell [mailto:ricardo.gladwell@btinternet.com]
>>Sent: Thursday, October 21, 2004 2:11 PM
>>To: Jakarta Commons Developers List
>>Subject: Re: [configuration] Concerns with ConfigurationRuntimeException
>>
>>
>>Emmanuel Bourg wrote:
>> > Let me know if I missed an exception.
>>
>>AFAIK, all actions throw the runtime exception ConversionException.
>>
>>
>>>I'm not fond of this. It only affects the configurations using an
>>>unreliable communication channel to access the properties, that's
>>>JNDIConfiguration and DatabaseConfiguration, the most widely used
>>>configurations are file based and not affected by this issue, why
>>>annoying their users ? Also this may prevent us from making
>>>Configurations implement the Map interface, I still want to try this.
>>
>>I would argue that all communcation channels have the potential to be
>>unreliable especially when you consider the IO API can be extended to
>>read/write data from  variety of source types. We cannot exclude the
>>possiblity of, for example, reading configuration information over
>>(unreliable) network connections. I don't this is an argument against
>>reporting exceptions in the underlying layer. Otherwise, would the
>>various IOException and SQLException also be runtime exceptions?
>>
>>I think, rather than force users to exit their programs on a
>>configuration error we should give them the option of either exiting
>>gracefully themselves or handling configuration exceptions unless we can
>>guanrantee that no exceptions will be thrown be by the code under all
>>circumstances (i.e. if disk is full, if hard disk is corrupted, etc) in
>>which case *we* have to handle the exception and recover from it. There
>>are many reasons for doing this, more importantly, so that users can
>>handle and recover from configuration read/write exceptions themselves.
>>
>>Another option would be to create an exception reporting mechanism
>>within the Configuration interface. Perhaps a method call
>>getExceptionsThrown() that returns a list of exceptions thrown during
>>the last few operations. Of course, this does mean that we are
>>re-creating the exception throwing mechanism implemented within
>>Java itself.
>>
>>
>>>I don't want to declare a ConfigurationException on every method of the
>>>Configuration interface, logging data access errors is fine imho, but
>>>there are some unexpected and undocumented runtime exceptions that
>>>should be removed (the most important is in
>>>JNDIConfiguration.getKeys()). The case of ConversionException should
>>>also be examined.
>>
>>It depends on why you are opposed to adding ConfigurationException to
>>all methods declartions in Configuration. If it's because it would
>>clutter the code with various try/catch blocks for users then I would
>>argue that this should not be an issue: reporting and handling
>>exceptions is a hassle but there is a very specific reason we have them.
>>I think the users would object more to the fact that
>>
>>Kind regards,
>>-- Ricardo
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 


-- 
Dipl.-Inform. Oliver Heger
Zentrale Informationsverarbeitung (ZIV) / Bereich Anwenderverfahren
Klinikum der Philipps-Universität Marburg
Baldingerstraße 3,
D-35037 Marburg
Tel: +49 6421 28-66592
mailto:oliver.heger@med.uni-marburg.de

---------------------------------------------------------------------
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