>Please note that Apache Avalon already has a very nice and flexible >Configuration object. �
>Could you let me know how your\'s differs? The Avalon Configuration is good. I think that one that is better: 1) Is not in Avalon but in commons 2) Allows for values and attributes at all levels in the tree, like mailer=My mailer [EMAIL PROTECTED] mailer.transportClass=nu.viggo.net.smtp.SMTPTransport 3) relies on the common Transformation/Conversion framework, in some kind of Transformation/Conversion component common for all common components, so that the configurator doesn\'t need to know all ways of transforming String data in the properties into real objects for the app. 4) Is tied to BeanUtils set/put/add methods, so that indexed properties and dictionary properties could be dynamically configured 5) Has support for the pool and the factories so that their usage is dynamically controllable from within the properties file. 6) Is subsystem based so that the writer of a subsystem defines what kind of data he or she needs for the app to work. The assembler of the whole app doesn\'t need to consider what the subsystems need, they tell the configuration framework what data they need. 7) Is beans based, so that the look of the config bean (holding all objects a subsystem needs to have configured) decides what must go in the config files, at the discretion of the sub system writer. 8) Manages a bunch of formats (traditional props, XML) as well as graphic config tools (yes, we need to convince the point-and-click-users as well) 9) Manages reconfiguration, so that the sub system writer doesn\'t have to. Etc. I have classes that performs some of this already. I will gladly donate them, but the power lies in the unbundling and integration of factories, transformation, pools etc, in commons as a whole, which is a greater matter. /O -------------------- [EMAIL PROTECTED] 0733 - 99 99 17 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
