> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
>
> Vadim Gritsenko wrote:
>
> >>From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
> >>
> >>Vadim Gritsenko wrote:
...
> >>>>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 !
Hold on... *Should* be an elegant way...
> 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}.
This is already taken place in the (each instance of) program
generator - is has an instance of program selector which does exactly
this - holds XSP handlers. This piece of code can be moved closer
towards SPG or...
> 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.
Can (is it wise?) SPG add returned handler to its manager? Like
manager.addComponent?
[don't have manager's API pinned on the wall ;)]
> So you end up potentially with 100 instances of a single XSP, and that
> *for each sitemap that uses it* !!!
No, that's definitely not the way I would go ;)
> IIRC, you were the one that raised the resource consumption issue
> related to duplicate components with different view labels ;)
Yep, I keep in mind idea about cocoonhost...
> >>Or did I miss something ? Do you want to create one
> >>component handler (and thus one pool) for each CM ?
That would be perfect (from my point of view).
> >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),
I still think that lookup in compose() (occurring ~once in a lifetime)
is faster then lookup in generate (on every request).
> - 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 !
You are missing to see alternative solution which hopefully exist! :)
...
> >>>
> >>>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.
Can I have a copy to place on my altar? ;)
> Please forgive me, mighty gods ;)
:)
Vadim
> 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]
