Well, it's supposed to provide an interface to allow the configuration to be modified and then deployed to runtime. I'm not sure how well ConfigurationBundle describes that.
Ah, ok, I looked at the interface you sent in email, and true, it doesn't describe it well. But, I would argue that the interface should be split, as I described in my first email on programmatic configuration.
You'd typically have 3 players involved:
1 Some configuration repository which the application can use to get configuration settings.
2 Some configuration bundle containing settings that have been loaded. This mostly just have get/set methods.
3 Various loaders which read configuration files (e.g. XML) and create configuration bundles and register these with the repository.
It then becomes possible to configure the app at runtime without using 3 at all, since 2 can be created programmatically. Instances of 2 can also be serialized and sent around in a system without much trouble.
It seems the current interface does 2 and 3. Split it up into ConfigurationLoader and ConfigurationBundle and it should work better.
/Rickard
------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
