-----Original Message----- From: Rickard Öberg [mailto:[EMAIL PROTECTED]
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.
This is the RuntimeConfiguration Interface. Both this and ProgrammableConfiguration are implemented by ConfigurationManager right now. This uses a very flat data structure. You call getActionConfig(String namespace, String name) to get an ActionConfig. The Package structures, etc. are stripped away as they're only used to provide defaults and inheritance.
Why is an interface needed here? I thought this was just a singleton thingy which the app can query. Are there several implementation possibilities, and if so, why?
2 Some configuration bundle containing settings that have been loaded. This mostly just have get/set methods.
This is ProgrammableConfiguration. It also has a reload() method to tell it to get the new configuration from 3, below, and buildRuntimeConfiguration(), which can be thought of as a "save" method which tells it to generate the runtime configuration from the hierarchical configuration structures which can be programmatically tweaked.
IMHO that's backwards. This thing should be a stupid data holder, nothing more. It's 3) that determines when the data should be reloaded.
3 Various loaders which read configuration files (e.g. XML) and create configuration bundles and register these with the repository.
This is ConfigurationFactory, which can have one object implementing
Configuration registered with it (by default this is
DefaultConfiguration).
That's backwards. It should be possible to have N implementations, one for each kind of configuration, simultaneously. Remember, an application may be created by merging several subapps, and each subapp may have its own way to read configuration. The total app must be able to handle this. With only One way to read configuration that is not possible.
When ConfigurationManager.reload() is called, it calls ConfigurationFactory.getConfiguration().init(this) to tell the Configuration to load its configuration and register the configuration params with the ProgrammableConfiguration it's passed (ConfigurationManager). DefaultConfiguration starts at init() and loads the xwork.xml file, parsing through it building up data structures and registering them with the ProgrammableConfiguration it is passed.
This is backwards, because how would you know when to call reload()? The only entity which can know this are the individual ConfigurationFactories.
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.
Hadn't thought of sending serialized configuration objects around. Why would you want to do this?
Why not? :-) Example: using JMX to configure. Using a Java client to configure. Storing serialized configuration in a database. Etc. etc.
Right now what happens is that ConfigurationManager has a static instance which is initialized at class initialization and calls reload to get the Configuration from the ConfigurationFactory.
See above. That's the wrong approach. Do you see why?
/Rickard
-- Rickard Öberg [EMAIL PROTECTED] Senselogic
Got blog? I do. http://dreambean.com
------------------------------------------------------- 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
