cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marco Rolappe" <m_rola...@web.de>
Subject AW: redirect handling, environment handling, etc.
Date Thu, 19 Feb 2004 13:12:59 GMT


> -----Ursprungliche Nachricht-----
> Von: dev-return-55870-m_rolappe=web.de@cocoon.apache.org
> [mailto:dev-return-55870-m_rolappe=web.de@cocoon.apache.org]Im Auftrag
> von Unico Hommes
> Gesendet: Donnerstag, 19. Februar 2004 13:33
> An: dev@cocoon.apache.org; m_rolappe@web.de
> Betreff: RE: redirect handling, environment handling, etc.
>
>
>
> Marco Rolappe wrote:
> >
> > ;-)
> >
> > the problems to be solved are the problems described: missing
> > processing key check, missing start/endProcessing around
> > ForwardEnvironment, storing the process key in the
> > environment's object model, etc.
> >
>
> OK, that is a memory leak then? Can you provide an anteater test for
> this?

I think it currently isn't a real leak (didn't test it, though), since the
start/endProcessing is not done for the ForwardEnvironmentWrapper, thus the
process key isn't overwritten (which would be done by startProcessing).
AFAICS this only has the consequence of an unreleased component
(SourceResolver) looked up by ForwardEnvironmentWrapper, but would also
leave behind request life cycle and auto release components stored in the
EnvironmentDescription (cleaned up by CCM.endProcessing).

I'll look into creating a correspinding test.

> > the real question probably is ;-): how? child environments
> > (since the ForwardEnvironment can't exist without a parent)?
> > or simply delegate calls like resolveURI to the
> > wrapped/parent environment?
>
> This reminds me of the patch you submitted last week for the redirect-to
> from sendPage() bug.

yeah, this whole TreeProcessor/'cocoon:/'
redirect/(Forward)EnvironmentWrapper intimacy is kind of hacky. on a
redirect ForwardEnvironmentWrapper just stored the redirect URL (i.e. both
for an internal and an external redirect), which SitemapSource is supposed
to use. for internal redirects this works, because ForwardRedirector sets a
corresponding environment attribute which TreeProcessor looks for. but
external redirects don't get through to the original (e.g. HttpEnvironment).
the patch propagates the redirect to the wrapped environment (it could
additionally store the redirect url for SitemapSource).

>
> > or have an Environment not
> > implement/be used as SourceResolver
>
> This is the approach taken in the 2.2 code base. Perhaps when that code
> grows up it can be ported to 2.1 module as well. Carsten can tell you
> more about that though.

good to hear. regarding 2.2, are only comitters supposed to contribute at
the moment? I'm playing with it at the moment and try to get stuff running
(e.g. server pages).


Mime
View raw message