What properties do you need in order to create the Configuration object? -------------------------------------------- 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 12:07 PM > To: [EMAIL PROTECTED] > Subject: RE: Anyone Review Configuration Changes? > > > Quinton, > Can you possible give me an example based on what I posted > earlier on what was in Tr.props? That might make it much clearer. > > You will definitly be able to override the tr.props with > stuff in web.xml. Check out this link for an example of > web.xml values overriding stuff in a properties file: > http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/configur > ation/src/test > -cactus/org/apache/commons/configuration/TestJNDIAndCompositeC > onfiguration.j > ava?rev=1.1&content-type=text/vnd.viewcvs-markup > > I guess what I am looking for is a bit more guidence on what > the bootstrap info should look like in the web.xml. Also, > for lots of properties (which in my example was three > seperate propeties, and could be more) web.xml may not be the > best place...? > > Eric Pugh > > > -----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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
