Konstantin, I like your idea about trying to make things easier. I have been wanting to write a JDBCConfiguration class, but haven't gotten around to it.
The BaseConfiguration works the way it does I think because it keeps config values in two seperate lists, correct? One in memory, and one loaded by the user? What if we instead create an AbstractConfiguration class that overrides everything. Then, when you implement your own, you just override the methods you want? Similar to the approach taken by java.util.AbstractList? If you can supply the code with unit tests, I would be very happy to review and commit it. As far as the NoSuchElementException etc.. I actually think only getObject should return null.. Or none of them maybe.. However, your idea for getProperty(String ke, Object defaultValue) would it return an Object? How would that be different then getObject()? Also, if you want to donate your JDBCConfiguration, it would be much appreciated... Eric Pugh > -----Original Message----- > From: Konstantin Shaposhnikov [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 25, 2003 2:30 PM > To: Jakarta Commons Developers List > Subject: Re: [configuration] Missed an email about providing a good > AbstractConfiguration class > > > Hello. > > Here is my previous mail: > --- > I've tried to create my own Configuration class which loads > properties > from database. Because I don't want to implement all methods from > Configuration interface by myself I decide to extend my class from > BaseConfiguration and found that it is not easy task. > > All methods which retrieve properties call private method > resolveContainerStore, which directly access store Map in which > BaseConfiguration store properties. So if I only want to > change way how > properties retrieved from underlying data store I also need > to override > all getProperty methods (JNDIConfiguration implemented in this way). > > There is easy solution for this problem. We can add new > protected method > in BaseConfiguration which provide way to retrieve property > values (and > call it f.e. getPropertyDirect) and replace all occurrence of > accessing > store map with call to this method. > > What do you think about it? > --- > > Also I have some more comments about implementation of > BaseConfiguration > class. May be we can discuss them too. I think that all getProperty > methods should behave similar. > > Now methods getBoolean, getByte, getDouble, getFloat, getInt, > getLong, > getShort which take only key as argument (without default > value) throw > NoSuchElementException if there is no element associated with > given key, > but getString and getObject methods behave different - they simply > return null. > > Also I think that method getProperty(String key, Object defaultValue) > also can be useful. > > > Eric Pugh wrote: > > Hi all, > > > > Someone sent I think to me directly an email about the > difficulty they had > > in creating a JDBCConfiguration object because of some cruft in the > > BaseConfiguration class in reponse to an earlier post I made. > > > > Unfortunantly I deleted it.. Could they resend it to the > list and maybe we > > can figure out how to make a nice easy to extend > BaseConfiguration class? > > > > Eric Pugh > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
