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