cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: AW: [C2]: Sitemap reloading - reconsidered
Date Mon, 02 Apr 2001 12:06:07 GMT
Quoting Carsten Ziegeler <cziegeler@sundn.de>:

> OK,
> 
> I think I can see again....(Perhaps some vacation might help here.....)
> 
> lets answer my mail by myself:

Your answer comes quicker than mine :)

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

Yes.

> 2. This request is served with the old sitemap

Yup.

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

Correct and in my optinion there is no need to tell'em.

> 4. The cocoon-reload parameter can be used to generate a new cocoon
> instance

The important word here is "new cocoon instance" which implies that a 
recompilation *may* occur only if the sitemap has been modified.

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

Here "generation of" means either recompilation, if modified or simply 
reinstantiation of the already compiled sitemap class.

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

Ok, here is the text from the servlet API:
    /**
     * Returns any extra path information associated with
     * the URL the client sent when it made this request.
     * The extra path information follows the servlet path
     * but precedes the query string.
     * This method returns <code>null</code> if there
     * was no extra path information.
     *
     * <p>Same as the value of the CGI variable PATH_INFO.
     *
     * @return          a <code>String</code>, decoded by the
     *                  web container, specifying 
     *                  extra path information that comes
     *                  after the servlet path but before
     *                  the query string in the request URL;
     *                  or <code>null</code> if the URL does not have
     *                  any extra path information
     */

I haven't tested it but I think on a URL http://localhost/cocoon/welcome the 
getPathInfo() should return "welcome" in any case and also the URL 
http://localhost/cocoon shoulöd return a null.

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

+0

> c) See my emails from today: Specifying a parameter in the web.xml which
> forbids regeneration of cocoon.

+1 Actually a cool thing would be if you can specify it in the sitemap and 
protect if by a host matcher (e.g. a url only allowed from localhost) but I 
can't see how to solve it because reloading is in the concern of the 
CocoonServlet not the sitemap itself.

Giacomo

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message