Henning, I think I get what you where suggesting, and the factory sounds right. What I am going to do is proceed like this:
If you provide a init param like this: <init-param> <param-name>turbine.config</param-name> <param-value>WEB-INF/conf/TurbineConfiguration.xml</param-value> </init-param> then I will use betwixt to load up the xml document TurbineConfiguration.xml that will build my composite configuration. I will provide a sample TurbineConfiguration.xml that just loads up TurbineProperties.properties for people to use. The code that does this will be the ConfigurationFactory() in commons-configuration. Turbine.java will look for the init param,a nd call ConfigurationFactory, otherwise it will function as before. Does this sound good to everybody? Eric PUgh -----Original Message----- From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 4:31 AM To: [EMAIL PROTECTED] Subject: Re: Anyone Review Configuration Changes? [EMAIL PROTECTED] writes: >Okay, >Here is my thinking now that I started writing code. Henning is right about >the dangers of a service. To have the config work, it must load FIRST, >before avaloncomponents or the regular components. Which means another >tweak to Turbine.java: This still doesn't help you. If you e.g. want to run completely from JNDI, you need at this points thinks like e.g. the logfile location. Or the information needed to bind to JNDI. >My idea was that the ConfigurationService would load, find the various >config settings required to load all the configurations. Populate a >CompositeConfiguration from that, (including the default TR.props config) >and then update the global Configuration. Then the later services all >loaded by the serviceManager would have the proper configurations. This leads to confusion because some parts of the Turbine will the start with the "configuration before ConfigService" and "after ConfigService". I'd propose that you do all this configuration stuff outside the Turbine scope and just in a commons-configuration scope. Add e.g. some System properties to set up the configuration and then we can add some code to the Turbine Startup to set the configuration up from the web.xml But please: We had so much ache and problems with the ResourceService which was a good idea at the time of the Turbine inception when there was nothing but the Java properties. But commons-configuration gives us much more room to breathe and if we work in that scope, we can still keep Turbine completely transparent to all kinds of configuration types. >Having said that, maybe what we need is more of a bootstrap config file. I No. Have a Factory (e.g. ATM we do Configuration c = (Configuration) new PropertiesConfiguration(propsPath); We might have here (Pseudo Code!): // New Configuration Factory. Does not exist yet! import org.apache.commons.configuration.SystemPropertiesConfiguration; String commonsConfig = findInitParameter("turbine.config", "properties:WEB-INF/conf/TurbineResource.properties"); SystemPropertiesConfiguration.setConfiguration(commonsConfig); // All file references are relative to this SystemPropertiesConfiguration.setApplicationRoot(applicationRoot); Configuration c = SystemPropertiesConfiguration.getCompositeConfiguration(); [...] So if you have <init-param> <param-name>turbine.config</param-name> <param-value>jndi:...some long and winded jndi config...</param-value> </init-param> then turbine would come up with the JNDI config or <init-param> <param-name>turbine.config</param-name> <param-value>xml:WEB-INF/conf/turbine.xml</param-value> </init-param> with the XML configuration. All you need is a simple factory that can parse a line like this: properties:WEB-INF/conf/TurbineResource.properties,jndi:...your jndi context... There is IMHO no need for a service. You can solve all these problems in the commons-configuration problem realm. And we get all these solutions for every other application using commons-configuration for free. Oh, and accept applicationRoot == null for "no application root". :-) Regards Henning -- Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH [EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/ Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance consultant -- Jakarta Turbine Development -- hero for hire --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
