cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject AW: [C2]: Sitemap reloading - reconsidered
Date Mon, 02 Apr 2001 11:26:00 GMT

I think I can see again....(Perhaps some vacation might help here.....)

lets answer my mail by myself:

> Carsten Ziegeler wrote:
> Hi,
> sorry I am now a little bit confused about all this sitemap reloading
> stuff....
> Perhaps someone can help me out of this, please.
> This is the story I though it was true until today:
> 1. If the sitemap is modified, it is recompiled.
> 2. The recompilation is in the background.
> 3. Until the recompilation is not finished the old sitemap is used.
> 4. using the cocoon-reload parameter, a recompilation is forced if the
> sitemap has been modified, the sitemap is compiled and the request is
> served with the new sitemap.
> This is exactly the way, C2 works with Tomcat 3.2.1. But looking into the
> code for this (CocoonServlet mainly) I didn't recognize parts 2-4. The
> ongoing discussion from today about the cocoon-reload parameter 
> showed that
> maybe my understanding is wrong:
> The getCocoon() method gets a new Cocoon instance, if
> 1. The sitemap has been modified
> 2. The cocoon-reload parameter is specified and the request.pathInfo is
> null
> 3. If no Cocoon instance is available, the cocoon-reload parameter
> specified and the request.pathInfo is null.
> But where is the compilation in the background specified? I must 
> be blind -
> I don't see it.
The compilation or generation of the sitemap either in the background or
not is done in the sitemap Manager. OK, I found this again.

So I think I understand this:
1. If the sitemap has been modified it is regenerated in the background by the next request.
2. This request is served with the old sitemap
3. There is no way to tell the Manager from the outside to wait for the regeneration of
   the sitemap and then serve the request.

4. The cocoon-reload parameter can be used to generate a new cocoon instance
5. The cocoon-reload parameter works only if the request.getPathInfo() returns null (very
technical I know)
6. If a new cocoon instance is created, a new sitemap is generated thus the request waits
for the 
   generation of the modified sitemap.
7. Some servlet engines return always null for request.getPathInfo() (like Tomcat 3.2.1) and
some only if the
   context itself is requested (like Bea 5.1)

So there are three open questions to answer:
a) Which implementation of request.getPathInfo() is correct?
b) Do we want a new cocoon instance via cocoon-reload only if the context itself is requested?
c) How do we protect C2 from DoS attacks?

My answers are:
a) I don't know...
b) Personally I think, it is very convenient to request any resource and to force a cocoon-reload.
c) See my emails from today: Specifying a parameter in the web.xml which forbids regeneration
of cocoon.

What do you think?


PS: I think we should address this in a beta as well - and here you have a volunteer for b)
and c) - if wanted - too

To unsubscribe, e-mail:
For additional commands, email:

View raw message