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?
Probably not needed. I just created them to keep me sane.
Ok. Then I'd propose that it's removed. :-) Let's keep simple things
simple. Sometimes you want flexibility and strategy possibilities, and sometimes you want rigidity and stability. This is a case of the latter I think.
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.
But you want to give the API users one thing to interact with, that being the ConfigurationManager. It's already got to know how to build the runtime configuration from the programmatic configuration.
Can't this be done when a configuration bundle is registered with the ConfigurationManager? Or, lazily upon access? Should work just fine as far as I can tell.
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.
That's a good point. We'll take it up with Patrick... I'll plead his starting that. :-)
In general, this "app created from subapps" is something that needs to be considered in all aspects. WebWork was monolithic in this sense, and it'd be good if we can move away from that. As I've already noted a couple of times, I think in the future it will be more common to build webapps from smaller webapps, e.g. through portlets.
This is backwards, because how would you know when to call reload()? The only entity which can know this are the individual ConfigurationFactories.
Okay. We can look at how this should be implemented. I still think the user needs to be able to trigger this programmatically, though, like a "refresh my config".
Ok, how about this then: have the configuration loaders be able to register with the configuration API, and on "refresh" simply give them a callback. That way the bundles (which should be *stupid*) does not contain logic that understand "refreshing". Then, any loaders that can reload can remove the previous configuration and add a new one.
I see your points, but I still think there are some details to be worked out. Check out the code and let me know how you think it should change.
There's always details to work out :-) I'll check it out.
/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
