I was thinking it would be good to let them be able to do a series of modifications to the programmatic configuration side then commit them all at once. The runtime configuration is not really a cache, it's another set of data structures that is built from the first set.
But, that data structure could be created on each call to the configuration, i.e. there's a deterministic way to get it from the registered package contexts. So, in *effect* it *is* a cache.
That's a good question. Are there any other frameworks we can look at for inspiration here?
Don't know. I was hoping your experience with Portals and Portlets would enlighten us :-)
Well, the portlet API uses an XML file similar to web.xml in order to "tie things together". It would be possible to do something similar here, where there is a main config file which is *always* XML, and in which one register the "parts" that are available, and which may use any configuration "style" to load it's particular configuration.
E.g.: <xwork> <!-- Register subapp "foo" which uses XML config --> <application name="foo"> <param name="config.xml">foo.xml</param> </application> <!-- Register subapp "bar" which uses DB config --> <application name="bar"> <param name="config.db">java:/BarDS</param> </application> </xwork>
Something like that. I think that the "top" needs to have a well-defined format though, in XML, similar to how web.xml works. As I said in an earlier post sometimes you want flexibility and sometimes you want rigidity. This is a place for rigidity.
/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
