Vadim Gritsenko wrote:
>>From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
>>
>>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 a 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 trying to manage components by
>itself?
>>>
>
>(1)
>
>>>Consider scenario: same XSP page is used in two sitemaps, but these two sitemaps
>have different component which 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 correct component from the correct
>sitemap. And, on sitemap reload, this handler 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 instances and composes 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
>manager.
>
IMO, this solution will be a performance and memory killer !
ServerPagesGenerator (SPG) is a front-end to _any_ XSP. Thus having
ProgramGenerator to return handlers means that each instance of SPG will
have to manage its own Map of {xsp-name, xsp-handler}.
Now SPG is also poolable (Generators can't be ThreadSafe). Let's suppose
that all pools are sized to 10 max. So you have 10 SPG, each one having
its Map of handlers containing each 10 instances of an XSP.
So you end up potentially with 100 instances of a single XSP, and that
*for each sitemap that uses it* !!!
IIRC, you were the one that raised the resource consumption issue
related to duplicate components with different view labels ;)
>>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 usercode
>>
>
>*sometimes*
>
>>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 :-/
>
Education won't be so hard, since recomposable has an impact only on
those XSPs that :
- override compose()
- lookup sitemap-specific components in the overriden compose()
And I guess that 99% of existing XSP either :
- don't lookup anything or lookup in generate() (should be 98% of them),
- override compose() to lookup "standard" (i.e. cocoon.xconf) components
(1%).
The remaining 1% will need to be changed, but these are advanced users
that shouldn't have much problems with that (remember that most users
don't even know they can declare methods in first-level <xsp:logic>)
Also, no logicsheet should override lifecycle methods : if two
logicsheets overriding the same method are used in an XSP, then the
generated code won't compile !
>What about returning handler? Seems like more clean approach to me.
>
Seems to me like an XSP-killer because of its overhead... or I'm really
missing something !
>>>>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 the 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
>recompose()).
>
>>or even initialize() to handle the
>>
>
>According to The Avalon Component Lifecycle Bible
>(http://jakarta.apache.org/avalon/framework/lifecycle.html) initialize
>must be called before recompose. I will not disturb the mighty gods of
>Avalon by implementing heretical order of lifecycle methods ;)
>
Damn ! How could I miss that one ! I have the order of lifecycle methods
pinned on my screen at work, but I'm at home. Please forgive me, mighty
gods ;)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
