cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject AW: AW: Cocoon Configuration Thoughts
Date Thu, 06 Jul 2000 12:53:54 GMT
Berin Loritsch wrote:

> > > Anyways, what would
> > > be the purpose of a dynamically reconfigured Cocoon?  It is a
> > > "cool" feature,
> > > but once a site has been built and configured, it really
> shouldn't change.
> > > What about having multiple instances in different Contexts?
> One for each
> > > version of Cocoon you need.
> > We have customers were the site MUST run 52x7x24. As the site is always
> > extended and enhenced, there is the need for updating the configuration
> > without stopping the site, even if this would be a short period.
> > On the other hand we are planning to configure more than currently the
> > covers, e.g. some configuration for
> processors etc. And
> > this information could change more often.
> You should also keep in mind that is going away
> in Cocoon2,
> which will be replaced by cocoon.xconf.  What this means that
> until that is
> released, dynamic configurations are going to be a pain.
> Considering what the file configures, I am
> having trouble
> thinking what should be added/removed/etc.  In a site like yours, I would
> leave everything active, and if you need it you use it.
> As for your custom Producers (which will become Generators in
> Cocoon2), I would
> use another mechanism besides the file to store your
> configuration information.  If you want the properties file format, then I
> suggest you keep that information separate and create a FileMonitor class
> that monitors the file in case it is ever changed.  Once it
> detects a change,
> it should repolulate the Properties object that you should
> already be referencing
> with the updates (only after it is completely read).  If you have
> your Properties
> object declared Static, then all of your instances of Producer
> will be reading
> the same information.
> This is a case where Caching the information in your instance can
> lead to a
> situtation you don't want.
Yes, but our current idea is that all started sessions use the old
configuration and only new session will use the new one. So in that case,
caching should do no harm (I hope)
> Hope this helps

Yes, indeed it dit. Thank you!
So I will look into the (configuration-) concepts of C2 now...

...this mail was scanned for viruses by mailserver...

View raw message