Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <44A92014.9060005@apache.org>
Date: Mon, 03 Jul 2006 15:48:04 +0200
From: Carsten Ziegeler <cziegeler@apache.org>
User-Agent: Thunderbird 1.5.0.4 (Windows/20060516)
MIME-Version: 1.0
To: Cocoon-Dev <dev@cocoon.apache.org>
Subject: [2.2] Setting up Cocoon and reloading
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

Daniel and I changed the way how Cocoon is setup in 2.2 in the last
week. Instead of doing everything in a single servlet, we now setup a
Cocoon Spring BeanFactory in a servlet listener. This bean factory is
stored as an attribute in the servlet context and can be retrieved by
any servlet component.
In addition we have a simple servlet now, which gets the container from
the attribute, gets the root tree processor from the container and
starts processing the request.
This is a very simple setup that should give us more flexibility in the
future.

The new approach provides all features the old CocoonServlet had with
one exception: reloading of the core. In Cocoon 2.1.x you can reload the
core by providing the "?cocoon-reload=true" parameter and if reloading
is turned on, the whole Cocoon instance is reloaded.

Now, the question is if we still need this feature. I started to add a
servlet filter for just reloading but then ran into some problems: for
reloading we need to setup a new bean factory and disregard the old
instance. First this has the same problem as we have with 2.1.x. What
happens if older requests are still processed? - We can neglect this as
this is a development only feature anyway.
But more interesting is, what happens with all the servlets, listeners
and filters out there who have a reference to the old container? We
could solve this by a facade if we want.
And another problem: this will setup a new cocoon instance, but a
possible root Spring context is not reloaded anyway.

So, due to all these problems I would suggest that we simply forget
about this feature. This can be handled by reloading the whole webapp
context through the application server which then really reloads
everything and takes care of old processes (in one way or the other).

Please note that this of course does not affect sitemap reloading which
still works without any problems.

WDYT?

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/