cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: Bug in TreeProcessor sitemap reloading?
Date Mon, 15 Apr 2002 18:42:40 GMT
> From: Sylvain Wallez []
> Vadim Gritsenko wrote:
> >Sylvain,
> >
> >>Vadim Gritsenko wrote:
> >>
> >>>
> >>>XSP page never gets new component manager on the sitemap
> >>>re-initialization.
> >>>
> >>
> >>This seems to be a bug in the way the XSP engine handles CMs :
> >>ServerPagesGenerator calls ProgramGenerator.load() with its own CM,
> >>which is then propagated down to JavaProgram which uses it to create
> >>ComponentHandler for the compiled XSP. The XSP is then stored in the
> >>ProgramGenerator cache.
> >>
> >
> >It seems to me that the bug not in the XSP engine but in the program
> >generator. May be it should return component handler instead of
> >to manage components by itself?


> Consider scenario: same XSP page is used
> >in two sitemaps, but these two sitemaps have different component
> >is looked up by XSP. In current implementation, XSP will get this
> >component from the sitemap who invoked this XSP first.
> >
> >If program generator returns handler, then every sitemap will get
> >handler for this XSP, with different manager -> XSP will lookup
> >component from the correct sitemap. And, on sitemap reload, this
> >will be disposed by the sitemap.
> >
> >Thoughts?
> >
> Mmmh... I'm not sure this will solve the problem : upon creation, the
> component handler creates a pool of XSP instaces and compose them with
> the CM it is given.

And this handler (with the pool) is returned to the component who called
program generator. After this, should be no issues with the manager:
handler was created with caller component's manager, and returned to
this component. If/when component gets new manager, it destroys the
handler and asks program generator for the new handler, with new

> Or did I miss something ? Do you want to create one
> component handler (and thus one pool) for each CM ?

Yes. This makes sense to me (see paragraph below (1)).

> We have to consider here the fact that component lookup in XSP user


> occurs within the generate() method, and thus after both compose() and
> recompose().

It is more efficient to obtain all the necessary components in the
(re)compose() method itself.

> So composing with the root CM and recomposing with the
> sitemap's CM should be OK.

Should be, if component understands (re)compose. You will have to
educate lots of users and ask them to rewrite their XSP pages to make
this work. I'm not happy about this :-/

What about returning handler? Seems like more clean approach to me. 

> >>Now the CM in ServerPagesGenerator is the local CM of the sitemap,
> >>created with the contents of <map:components>. When the sitemap is
> >>reloaded, this CM is disposed and a new one is created. But the 
> >>cached XSP still references the previous CM which is now disposed.
> >>
> >>This bug doesn't exist in the compiled engine because a compiled 
> >>sitemap doesn't have a local CM, but only a set of selectors for
> >>each component type and thus the XSP uses Cocoon's root CM.
> >>
> >>IMO, to solve this problem, the ProgramGenerator should use its
> >>own CM (i.e. Cocoon's root CM) to get a ComponentHandler and then
> >>make  XSPGenerator (or AbstractServerPage?) recomposable so that 
> >>it gets the correct sitemap CM.
> >
> >This does not work for sitemap compilation: it must be created with
> >parent sitemap manager in order to inherit components configured in
> >parent.
> >
> >I rolled back some of the changes - but left recomposable.
> >
> What about moving the code in AbstractSitemap.compose() to
> AbstractSitemap.recompose(),

It might work, but will introduce minor overhead of double
initialization (first - compose(), then subset of dispose(), then

> or even initialize() to handle the

According to The Avalon Component Lifecycle Bible
( initialize
must be called before recompose. I will not disturb the mighty gods of
Avalon by implementing heretical order of lifecycle methods ;)


> hypothetical case where recompose() isn't called ? Won't this solve
> problem ?
> >>Thoughts ? Does this affect also the JavaScript XSP engine ?
> >>
> >
> >Yes - if XSP needs to get some component.
> >
> So it needs to be made recomposable also.
> Sylvain
> --
> Sylvain Wallez
>  Anyware Technologies                  Apache Cocoon

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

View raw message