Well,
It kind of depends on what type of configuration object it is.
For a PropertiesConfiguration, you need a file.
For a JNDIConfiguration, you need a prefix like java:env etc.
So, it means that there are quite a few settings. Additionally, we need to
specifiy either some sort of magic key for the type of class to load, or a
classname.
I don't really know how to proceed, because I am also thinking of maybe
using betwixt. Maybe you have a file:
configuration.xml with something like this for loading a tr.props file and a
jndi context;
<configurations>
<configuration>
<className>org.apache.commons.configuration.PropertiesConfiguration</classNa
me>
<fileName>/web-inf/conf/TurbineResources.properties</fileName>
</configuration>
<configuration>
<className>org.apache.commons.configuration.JNDIConfiguration</className>
<prefix>java:comp/env</prefix>
</configuration>
</configurations>
Theoretically, Betwixt could load this up, and create your
CompositeConfiguration object based on this file.
However, to make things backwards compatable, we might need to put a setting
into TR.props, or do something in Turbine.java like:
If I have a servlet config value "configuration" provided, then use that, to
load up a configuration.xml via betwixt. Otherwise expect to have servlet
config value "properties" that points to the old TurbineResources.properties
and use that.
Sound good? So the new way would be:
<servlet>
<servlet-name>fortius</servlet-name>
<servlet-class>org.apache.turbine.Turbine</servlet-class>
<init-param>
<param-name>configuration</param-name>
<!-- This is relative to the docBase -->
<param-value>
/WEB-INF/conf/Configuration.xml
</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Eric Pugh
-----Original Message-----
From: Quinton McCombs [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 2:12 PM
To: Turbine Developers List
Subject: RE: Anyone Review Configuration Changes?
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]
