commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [configuration] XmlConfiguration
Date Wed, 11 Dec 2002 17:51:36 GMT
There are 2 existing APIs to abstract config storage: one is the JDK1.4 
prefs, the other one is JNDI. Each provides plugin mechanisms for
arbitrary storage ( XML, props - win registry, ldap, etc ).

There are several different philosophies for configuring applications -
push and pull are the major directions. 

There are 2 APIs config ( push-style ): JMX and JavaBeans. 
( for Pull - either JNDI or prefs can be used directly ).

I think we have more than enough. I don't see myself working on (or using)
any new config API. JMX and Beans for push are pretty clear. Prefs
is not acceptable ( since it's tied into JDK1.4 ), but JNDI is widely
used and extremely flexible. ( the only downside is the huge number 
of methods a provider must implement - that can be solved with some
base classes )

Regarding the "implement all features" aproach - one important feature
is the footprint and complexity of the config. It would be quite hard
to combine it with all others.


Ola Berg wrote:

>> 10 other projects also have their implementation and they don't want to
>> switch :-((((
>> it definitly doesn't make sense to have 10 implemetations for something
>> like reading an xml config file!!!
>> is it really impossible to find a solution which can be used by all
>> projects??
>> let's join forces to find a way to have one configuration package!!!
> Hint (if you think it is worth it):
> 1) Check out the 10 implementations, factor out a common denominator API.
> 2) Merge all features from all implementations so that your thing will be
> the most featuresque of them all (so that the potential "customers" won't
> lose anything in the transition), and thus expanding the API from 1)
> above.
> 3) Sell it to them by offering replacement classes that adapts your thing
> to theirs (a slip-in-replacement).
> 4) Offer the added functionality on their email lists, pushing the
> benefits of your thing.
> Why I don't think that the above will work is that
> a) the installed base is too big,
> b) configuration is such a core feature of your product so that you want
> to retain full release/bugfix/management control over the configuration
> component
> and
> c) The different APIs take different approaches, esp when in the
> configuration process, and how, the provided String values get converted
> into real objects.
> I welcome better config utilities (even though I know that the existing
> impls are good enough for about any case), but I think that when doing
> such a thing, considering your answer to point c) is of great importance.
> I have limited coding possibilities as of now, but I am with you in
> thinking (feature requests, modelling, opinions etc).
> I prefer seeing XML config files as a special case of XMLalizing
> object/bean structures.
> /O

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message