Here's what I'm thinking:
1) Remove the ManageableConfiguration Interface (was ProgrammableConfiguration) - this is just ConfigurationManager 2) Make RuntimeConfiguration into a class and move that part of ConfigurationManager over to it
There will always be only one RuntimeConfiguration which is created by ConfigurationManager from the configuration structures it holds which are initialized by the ConfigurationProviders
I'm having a little trouble seeing exactly what it would lead to, so hard to comment on. Just do it, and I'll look at the end result.
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.
The problem here is the case of programmatic configuration. If someone writes code to call into the ConfigurationManager to change the configs, then they need to be able to generate the runtime configuration from it.
If someone adds/removes configuration -> clear cache. When a value is needed -> either rebuild the entire cache or just the cache for that value.
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.
I agree. How would the sub-apps configuration get loaded? How are they packaged?
That's a good question. Are there any other frameworks we can look at for inspiration here?
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.
This is what it does now. Here's the reload() method on ConfigurationManager:
public synchronized void reload() throws ConfigurationException { packageContexts.clear(); ConfigurationProvider config =
ConfigurationProviderFactory.getConfig(); config.init(this); buildRuntimeConfiguration(); }
This, in order, clears the current data structure, gets the ConfigurationProvider (which could be changed to a List of ConfigurationProviders) and tells it (them) to init, passing it this so that they can call back to the ConfigurationManager to register configurations, then it builds the runtime configuration from the registered configurations.
Ok. I'll have to look at the code to see all the implications of this I think.
/Rickard
------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
