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]
