Oh, one more thing. As I wrote my unit tests for my ConfigurationService, I realized I had a stack of issues with the code in commons-configuration. I have since applied all the patches and now my test for ConfigurationServicer is working. Quinton, if you get a chance, can you regenerate the jar for maven assuming they haven't grabbed it yet? If you don't have time, that is fine. I am sure there will be other changes to commons configuration before I am done.
Eric -----Original Message----- From: Quinton McCombs [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 1:06 PM To: Turbine Developers List Subject: RE: Anyone Review Configuration Changes? I think that all of the bootstrap information should come from web.xml. I don't really see any need for an additional configuration file. I would also like to see configuration data supplied in web.xml override TR.props. -------------------------------------------- Quinton McCombs NequalsOne - HealthCare marketing tools mailto:[EMAIL PROTECTED] http://www.NequalsOne.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 11, 2003 10:58 AM > To: [EMAIL PROTECTED] > Subject: RE: Anyone Review Configuration Changes? > > > I'm sorry, I actually wrote the configuration service. > However, I don't want to go too far down the road without > buyin from everybody. I guess what I meant is that was the > tweak (the loop hole) that I had to make to Turbine.java. > > So, is the consensus that we load up a minimal prop file, and > then use that to bootstrap all the config stuff from? Or > does someone have an example web.xml to share. > > Eric > > -----Original Message----- > From: Quinton McCombs [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 11, 2003 11:54 AM > To: Turbine Developers List > Subject: RE: Anyone Review Configuration Changes? > > > No. There is no configuration service. Look at how the > current code works. > > -------------------------------------------- > Quinton McCombs > NequalsOne - HealthCare marketing tools > mailto:[EMAIL PROTECTED] http://www.NequalsOne.com > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 11, 2003 10:47 AM > > To: [EMAIL PROTECTED] > > Subject: RE: Anyone Review Configuration Changes? > > > > > > 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: <snip> // > > // Be sure, that our essential services get run early > > // > > configuration.setProperty(TurbineServices.SERVICE_PREFIX + > > > > ConfigurationService.SERVICE_NAME + ".earlyInit", > > new Boolean(true)); > > > > configuration.setProperty(TurbineServices.SERVICE_PREFIX + > > > > ComponentService.SERVICE_NAME + ".earlyInit", > > new Boolean(true)); > > > > configuration.setProperty(TurbineServices.SERVICE_PREFIX + > > > > AvalonComponentService.SERVICE_NAME + ".earlyInit", > > new Boolean(true)); > > > > serviceManager.setConfiguration(configuration); > > <snip> > > > > 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. > > > > Having said that, maybe what we need is more of a bootstrap > > config file. I don't know how important backwards > > compatiblity is, but we could say the if you use this code, > > then the default tr.props because a boot strap that specs out > > all the configfiles. (one of which could be itself). Then, > > instead of a service, we just go ahead and create the > > CompositeConfiguration right in the Turbine.configure() > > method. This then would be backwards compatable. > > > > However, if there are other suggestions, please make them! > > > > ERic > > > > -----Original Message----- > > From: Quinton McCombs [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 11, 2003 11:14 AM > > To: Turbine Developers List; [EMAIL PROTECTED] > > Subject: RE: Anyone Review Configuration Changes? > > > > > > I am all for moving stuff into web.xml. > > > > -------------------------------------------- > > Quinton McCombs > > NequalsOne - HealthCare marketing tools > > mailto:[EMAIL PROTECTED] http://www.NequalsOne.com > > > > > -----Original Message----- > > > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, March 11, 2003 9:58 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Anyone Review Configuration Changes? > > > > > > > > > [EMAIL PROTECTED] writes: > > > > > > >Secondly, > > > >I am thinking about the CompositeConfiguration stuff as working > > > >somewhat similar to how the various schedular jobs are > > listed in the > > > >TR.props. Basically something like this: > > > > > > >services.ConfigurationService.configurations=propertiesSource > > > ,JNDISourc > > > >e > > > > > > >services.ConfigurationService.configurations.propertiesSource > > > .file=/web > > > >-inf/ > > > >conf/MyProperties.props > > > > > > Then we're back on "ResourcesService", which got removed > > for 2.3-dev. > > > > > > The problem with "logging" and "configuration" is, that these are > > > special. You simply can't move this stuff into services without > > > starting to build loopholes and shortcuts, because > without logging > > > and configuration, you can't do very much else. > > > > > > >services.ConfigurationService.configurations.JNDISource.prefi > > > x=java:com > > > >p/env > > > > > > Stuff like this must IMHO come from the web.xml or from a > very very > > > small "meta" configuration file (which might simply be a sub > > > category of the TR.props) that gets parsed only with > Properties or > > > XML Configuration. > > > > > > Using a service for this got tested in T2.0 and T2.1 It > > does not work. > > > > > > 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] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
