cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianugo Rabellino <>
Subject Re: [RT] Configuring Cocoon
Date Thu, 17 Feb 2005 11:09:11 GMT
On Thu, 17 Feb 2005 08:45:33 +0100, Carsten Ziegeler
<> 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

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 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. :-)

Gianugo Rabellino
Pro-netics s.r.l. -
Orixo, the XML business alliance:
(blogging at

View raw message