The concept behind the compositeConfiguration object is that the config objects added first are used, and the others ignored.
This allows you to have a config specific to an environment, and then a second config file with vanilla settings. If you put a value in the firstone, then it overrides the value in the second one. So, for the services stuff, since you probably would have the same services always, you wouldn't override them. But for the template cache settins or reload settings, you might want one set in dev, another in test, and yet another in prod. Those "override" values could be in .properties, .xml, or JNDI! Eric -----Original Message----- From: Quinton McCombs [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:18 AM To: 'Turbine Developers List' Subject: RE: Fragileness in PullService and VelocityService How will you handle services being configured in multiple property files? Specifically, I am talking about the services.PoolService.classname=<classname> type entries. -------------------------------------------- Quinton McCombs NequalsOne - HealthCare marketing tools mailto:[EMAIL PROTECTED] http://www.NequalsOne.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 18, 2003 7:34 AM > To: [EMAIL PROTECTED] > Subject: RE: Fragileness in PullService and VelocityService > > > You are correct about the existing config file honors the > order of things.. However, when wrapped in a > CompositeConfiguration object (which allows multiple property > files, plus xml based property files) then the order become > uncertain, not set.. > > I suppose I will dig into the code and figure out why the > order is not set, and make it honor the order of the properties. > > Eric > > -----Original Message----- > From: Eric Dobbs [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 17, 2003 5:40 PM > To: Turbine Developers List > Subject: Re: Fragileness in PullService and VelocityService > > > Hi All. > > This conversation is sounding *really* familiar. I thought > the existing turbine config already honored the order of > services as they are organized in the config file. > > On Tuesday, June 17, 2003, at 01:46 PM, [EMAIL PROTECTED] wrote: > > > Oh, I believe the use case! I just am trembling in fear of > actually > > attempting to add the "state the dependencies" in the > existing Turbine > > services system. One of the reasons for using Avalon components is > > that you > > can do that! > > > > I guess that means I have to tweak/hack/ otherwise brutalize the > > configuration code to perserve order. > > > I thought that was fixed a couple years ago. I dug through > mail archive and found this which is what I think I'm > remembering: > <http://www.mail-archive.com/[EMAIL PROTECTED]/ msg00757.html> On Tuesday 29 May 2001 10:29, John Thorhauer wrote: > On Tuesday 29 May 2001 05:12, Jon Stevens wrote: > > Yup. That is exactly the problem. We need to reverse the order of > > startup. > > Actually it looks to me like the mapping is not holding its order properly. > I am not very familiar with the Configuration object but the comments in > TurbineServices say that the it is used because it will keep the order > correctly. Does anyone know if this actually works? At the end of the thread John provided a patch to the BaseServiceBroker which is unfortunately not in the easier- to-read 'diff -u' format: <http://www.mail-archive.com/[EMAIL PROTECTED]/ msg00758.html> Hope that helps. -Eric (Dobbs) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
