Re: [RT] Configuring Cocoon
On Thu, 17 Feb 2005 08:45:33 +0100, Carsten Ziegeler
[EMAIL PROTECTED] wrote:
I think you missed the point. 99% of cocoon.xconf belongs in the war
file, hidden away. However, there are a few configuration items such as
the pool sizes that need to be configured when Cocoon is started, not
when the war is built. IMO, that is the value of Carsten's enhancement.
Exactly :)
Now, it doesn't make sense to me to have copies of the whole
cocoon.xconf or logkit.xconf just because one or two values are
different. That's not maintainable.
It is maintainable if those files are automatically generated from a
common template. OTOH, how can be more maintainable having the same
configuration data split over two different resources, one of which
can reside in four different places, resolved at runtime? I kinda
expect all sort of weirdos happening... and I still feel that this is
a hackish way to solve a real issue which might deserve more
attention.
Ralph is right saying that a few configuration data belong to the
sysadmins. Having been a sysadmin myself, I used to complain a lot
about the missing SoC in the average Java applications configuration
files, where developer-oriented information is intermixed with
performance and system administration. However the solution to me is
pinning out those settings who belong to the application
administration and provide a (tool/file/registry) for them.
Let's take pool settings as an example: I don't feel that
pool-max=${whatever} * 10 / 2} is a good solution: what if
${whatever} is unspecified? How would you log the failure? How would
you log what is the actual runtime setting been applied when you're
trying to debug a performance problem, just to find out that you had a
stale cocoon-setting.properties lying somewhere and having precedence
on your carefully tuned setting? Me, as a sysadmin, would be quite
pissed about this indirection mechanism: I sure want a way to
configure my application easily, which means that I need clear
directions and possibly tools for that: what I definitely don't need
is an arbitrarily opaque setting in a config file, requiring me to
hunt for the real data somewhere else.
But hey, sysadmining is purely a matter of taste, and this starts
looking much like bikeshedding: so don't bother about me being an old
fart and go ahead. I'll keep for myself the pleasure of stating an I
told you so at a proper time. :-)
Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. - http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)
[RT] Configuring Cocoon
One of the big challenges is to configure Cocoon when the same
application is used in different environments. For example when each
developer uses his own database.
With 2.2 things get easier: first, the big cocoon.xconf is split into
various little parts that can be handled more easily. But that allone
doesn't really help. There are more configuration values hidden in web.xml.
So I have the following suggestion that I already implemented as a
prototoype:
a) Use of properties in all xconf files. If you write ${my.property}
then this is replaced during loading of the xconf with the actual
value of the property. - for compatibility, if there is no value
for this property, the reference is left in place.
There are different ways to specify properties as you will see soon,
for now this is just a system property: so if you start Cocoon with
-Dmy.property=something it gets replaced.
b) The web.xml is imho a bad place for Cocoon configurations as these
are not very visible, and even more important you don't have a
web.xml in other environments like the cli. So you end up with
different places for configuration for different environments.
To solve this I added a property configuration mechanism, so every
configuration value (that is not servlet specific) can be configured
in a properties file.
Cocoon uses the following sources to detect properties:
- First the resource cocoon-settings.properties is read from the
classpath. This is the location were we can define all the default
values. It's better to have default values in a separate file than
somewhere hidden in the Java source.
- Second, the configuration from web.xml is read and this overrides
values from the first phase (only for servlet env of course).
- Third, if a system property org.apache.cocoon.settings
is specified, the appropriate file is read and settings from here
override those of the two preceeding phases.
- Finally system properties are evaluated and may define the final
configuration value.
Example:
cocoon-settings.propeties:
org.apache.cocoon.allow.reload=false
org.apache.cocoon.configuration=/WEB-INF/cocoon.xconf
web.xml:
parameter for allow-reload with the value false
System Property on startup: -Dorg.apache.cocoon.allow.reload=true
Then the allow-reload is set to true as the system properties have
the last saying.
With this dynamic property configuration, it's easy to configure
Cocoon for different environments. Each developer can start Cocoon
with his own settings without changing the configuration files.
With the second option from above, each developer can have his own
properties file overriding specific values, so there is no need to
specify all properties as system properties on startup.
c) Next to the settings of Cocoon, all property files can have
additional properties, for example:
myapplication.databaseurl=jdbc://
All these properties, defined as system properties or in the property
files read by Cocoon, can be used in the xconf files, so
you can just write ${myapplication.databaseurl} and it get's
properly replaced.
Now, I think this is a very handy feature: each developer just has his
own configuration file with his local settings and specifies this on
startup and things like database connections etc. are properly replaced.
There is no need to hand edit the configuration files anymore.
In addition, if you just want to change a value for testing, specify
it on startup. Just try starting Cocoon with
-Dorg.apache.cocoon.allow.reload=true
and the cocoon.xconf get's reloaded (ok, there's the ehcache problem).
Internally, I created a new bean: the settings object that holds all the
core configuration. The settings can be seen by the status generator and
are logged (using DEBUG log level).
All names for the properties are defined in the Settings file; I just
randomly choose some names; I guess they need some cleanup.
I implemented this as a prototype for the servlet environment, the other
environments are a todo.
So, WDYT?
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: [RT] Configuring Cocoon
Gianugo Rabellino wrote:
On Wed, 16 Feb 2005 11:42:06 -0800, Ralph Goers
[EMAIL PROTECTED] wrote:
Carsten Ziegeler wrote:
a) Use of properties in all xconf files. If you write ${my.property}
then this is replaced during loading of the xconf with the actual
value of the property. - for compatibility, if there is no value
for this property, the reference is left in place.
There are different ways to specify properties as you will see soon,
for now this is just a system property: so if you start Cocoon with
-Dmy.property=something it gets replaced.
So, WDYT?
I'd love this in 2.1. This would really help with configuring pool
sizes - especially if it could be done something like:
pool-max=${max_users}*10
Which is exactly what I'm afraid of. Instead than solving the real
issue (a painful configuration model), this looks like a workaround
easily leading to abuses. I'm not sure that adding a fourth
configuration point (web.xml, cocoon.xconf, logkit.xconf) is a good
long term solution. Even more if you consider how easily property
files, read from four different points, might bring unexpected
results, effectively making the configuration even more opaque.
You might get a similar yet much more predictable and controlled
result using off-line generation of configuration files from
templates: runtime expansions smells trouble to me.
Ciao,
The problem with cocoon.xconf is that it is part of the war file. This
makes it very difficult for our operations folks to change it since it
will get over-ridden each time the app is redeployed. Unfortunately,
they are the best ones to know just how much resources they are going to
give the JVM. While we might know, the average of how many times a
particular transformer is used in pipelines, they will be the ones
determining just how many users they want each instance to support.
This makes that an ideal value for something that should be configured
outside the webapp. However, other configuration items are better left
in cocoon.xconf inside the war because they shouldn't be changed. On
the other hand, locating logkit.xconf inside the webapp would be most
irritating if I hadn't replaced the default log manager with something else.
From my point of view, things that make sense to be modified by the
operations staff belong in a properties file or an XML file external to
the webapp.
Ralph
Re: [RT] Configuring Cocoon
The problem with cocoon.xconf is that it is part of the war file. This makes it very difficult for our operations folks to change it since it will get over-ridden each time the app is redeployed. Doesn't have to be. The location of the .xconf is specified in web.xml (now, if you ask me, it could well be a system property). This is how exactly how we handle different configurations: they are stored elsewhere (actually version-controlled inside the project itself) and referenced by the web.xml setting. Same for logkit.xconf. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [RT] Configuring Cocoon
Gianugo Rabellino wrote: The problem with cocoon.xconf is that it is part of the war file. This makes it very difficult for our operations folks to change it since it will get over-ridden each time the app is redeployed. Doesn't have to be. The location of the .xconf is specified in web.xml (now, if you ask me, it could well be a system property). This is how exactly how we handle different configurations: they are stored elsewhere (actually version-controlled inside the project itself) and referenced by the web.xml setting. Same for logkit.xconf. Ciao, I think you missed the point. 99% of cocoon.xconf belongs in the war file, hidden away. However, there are a few configuration items such as the pool sizes that need to be configured when Cocoon is started, not when the war is built. IMO, that is the value of Carsten's enhancement. Ralph
Re: [RT] Configuring Cocoon
Ralph Goers wrote: Gianugo Rabellino wrote: The problem with cocoon.xconf is that it is part of the war file. This makes it very difficult for our operations folks to change it since it will get over-ridden each time the app is redeployed. Doesn't have to be. The location of the .xconf is specified in web.xml (now, if you ask me, it could well be a system property). This is how exactly how we handle different configurations: they are stored elsewhere (actually version-controlled inside the project itself) and referenced by the web.xml setting. Same for logkit.xconf. Ciao, I think you missed the point. 99% of cocoon.xconf belongs in the war file, hidden away. However, there are a few configuration items such as the pool sizes that need to be configured when Cocoon is started, not when the war is built. IMO, that is the value of Carsten's enhancement. Exactly :) Now, it doesn't make sense to me to have copies of the whole cocoon.xconf or logkit.xconf just because one or two values are different. That's not maintainable. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
