Hi All, Have been following this thread with interest since putting forward my 2c early on.
Just wanted to to wade in again with another real-world usecase, albeit one from the point of view of someone who's solution depends on a fair bit of customization to server.xml: 1. cleaning up the code by removing configuration beans: sounds fine to me, as long as I can work out how to achieve what I do today in the new regime 2. storing configuration in the DIT: I understand the benefits for replicating configuration across a cluster etc, and don't mind too much as long as I and my more tech-savvy customers don't have to struggle too hard to achieve the saem changes they can make today 3. flattening out all config setting/wiring into LDAP: don't like this idea at all and agree with Ersin, LDAP works best for a smallish number of objectclasses with a smallish number variation across them. Some basic settings can be expressed as attributes on well known LDAP objects (e.g. default environment for the server) but representing a tree of custom plug-in beans on config beans that aren't even part of the ADS source (as I do) sounds like its going to be a considerable PITA to me. Using server.xmlI can change a string config setting to a bean with three attributes smoothly if I need to, with an LDAP solution I presume I'd need a new objectclass or some hacky "generic objectclass" which has attributes called attr1,..., attrN. Yours nervously, Norval
