[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]
