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]

Reply via email to