[EMAIL PROTECTED] writes:
>Henning,
>I think I get what you where suggesting, and the factory sounds right. What
>I am going to do is proceed like this:
>If you provide a init param like this:
><init-param>
> <param-name>turbine.config</param-name>
> <param-value>WEB-INF/conf/TurbineConfiguration.xml</param-value>
></init-param>
>then I will use betwixt to load up the xml document TurbineConfiguration.xml
>that will build my composite configuration.
Hi,
I still would prefer not to have another configuration file, or even
if we have, then please use some sort of namespace to load your
"configuration configuration" so we can put this meta-config and the
config itself into one file.
I suggest this, because the 99% case will be that users have all their
configuration in a single TR.properties (or TR.XML or an Avalon config
file, whatever) and I don't want to make this case unnecessary
complicated.
Think (fictional XML code)
<configuration xmlns:meta="turbine-meta-config"
xmlns:turbine="turbine-config">
<meta>
<jndi ...parameters for jndi... />
<file type="xml" namespace="turbine" name="/WEB-INF/conf/Turbine.xml"/>
<file type="properties" name="/WEB-INF/conf/Turbine.properties"/>
<file type="avalon" name="/WEB-INF/conf/AvalonTurbine.xml"/>
</meta>
<turbine>
....
</turbine>
</configuration>
with your betwixt just parsing the meta namespace.
>I will provide a sample TurbineConfiguration.xml that just loads up
>TurbineProperties.properties for people to use.
Still, I don't like the fact that we now have _another_ config
file. But then, this is IMHO commons-configuration problem realm. :-)
I did take a look at the avalon-framework configuration component and
I think that it is more flexible in many respects than c-c but I don't
like the fact that we get locked into XML configuration which will be
a pain for users to convert (transition via c-c from properties to
properties/xml to xml might be easier) and I think that the various
components using the configuration will have to work harder than they
do now to get e.g. arrays of strings.
To start such a transition, it would be nice to get the XMLConfiguration
of C-C off the ground and start using it post Turbine-2.3
>Turbine.java will look for the init param,a nd call ConfigurationFactory,
>otherwise it will function as before.
>Does this sound good to everybody?
I don't like the name of the property. We don't have any "." property
in the web.xml yet, web have "webappRoot, loggingRoot and applicationRoot"
Let's call this "configuration" or "metaConfiguration" because it is not
the "real" configuration.
All in all, I'm +0 to your proposal but I think it needs some more
clarification.
Regards
Henning
>Eric PUgh
>-----Original Message-----
>From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, March 12, 2003 4:31 AM
>To: [EMAIL PROTECTED]
>Subject: Re: Anyone Review Configuration Changes?
>[EMAIL PROTECTED] writes:
>>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:
>This still doesn't help you. If you e.g. want to run completely from
>JNDI, you need at this points thinks like e.g. the logfile location. Or
>the information needed to bind to JNDI.
>>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.
>This leads to confusion because some parts of the Turbine will the start
>with the "configuration before ConfigService" and "after ConfigService".
>I'd propose that you do all this configuration stuff outside the Turbine
>scope and just in a commons-configuration scope. Add e.g. some System
>properties to set up the configuration and then we can add some code
>to the Turbine Startup to set the configuration up from the web.xml
>But please: We had so much ache and problems with the ResourceService
>which was a good idea at the time of the Turbine inception when there
>was nothing but the Java properties. But commons-configuration gives
>us much more room to breathe and if we work in that scope, we can
>still keep Turbine completely transparent to all kinds of
>configuration types.
>>Having said that, maybe what we need is more of a bootstrap config file. I
>No. Have a Factory
>(e.g. ATM we do
>Configuration c = (Configuration) new PropertiesConfiguration(propsPath);
>We might have here (Pseudo Code!):
>// New Configuration Factory. Does not exist yet!
>import org.apache.commons.configuration.SystemPropertiesConfiguration;
>String commonsConfig = findInitParameter("turbine.config",
>"properties:WEB-INF/conf/TurbineResource.properties");
>SystemPropertiesConfiguration.setConfiguration(commonsConfig);
>// All file references are relative to this
>SystemPropertiesConfiguration.setApplicationRoot(applicationRoot);
>Configuration c = SystemPropertiesConfiguration.getCompositeConfiguration();
>[...]
>So if you have
><init-param>
> <param-name>turbine.config</param-name>
> <param-value>jndi:...some long and winded jndi config...</param-value>
></init-param>
>then turbine would come up with the JNDI config
>or
><init-param>
> <param-name>turbine.config</param-name>
> <param-value>xml:WEB-INF/conf/turbine.xml</param-value>
></init-param>
>with the XML configuration. All you need is a simple factory that can parse
>a line like this:
>properties:WEB-INF/conf/TurbineResource.properties,jndi:...your jndi
>context...
>There is IMHO no need for a service. You can solve all these problems
>in the commons-configuration problem realm. And we get all these solutions
>for every other application using commons-configuration for free.
>Oh, and accept applicationRoot == null for "no application root". :-)
> 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]
>------_=_NextPart_001_01C2ECD1.E44C97A0--
--
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]
