> -----Original Message----- > From: Rickard Öberg [mailto:[EMAIL PROTECTED] > > 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. > >> 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. 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. > > > 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. > That's a good point. We'll take it up with Patrick... I'll plead his starting that. :-) > > 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. 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". > > >> 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? > 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. Jason ------------------------------------------------------- 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
