cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] The API for the request object
Date Tue, 06 Jul 2004 20:37:43 GMT
Leszek Gawron wrote:

> Vadim Gritsenko wrote:
>> Jeremy Quinn wrote:
>>> On 6 Jul 2004, at 11:13, Sylvain Wallez wrote:
>>>>> Now, the basic mechanism for this could be to scan all attribute 
>>>>> values of the request and find out if the value should be cleaned 
>>>>> up or not. This could be done by either testing for the usual 
>>>>> suspects from Avalon (Disposable, Recyclable) or by defining a new 
>>>>> Cocoon specific interface.
>>>>> But perhaps there is a better way?
>>>> What about adding a list of ProcessingListeners to the object 
>>>> model, which can be augmented by the various components that 
>>>> participate in request handling, and is called at particular places 
>>>> such as:
>>>> - processing start (such listeners must be registered in the xconf),
>>>> - sitemap mount,
>>>> - end of pipeline building,
>>>> - start of pipeline execution (differs from the previous one as it 
>>>> may not be called if the result is cached)
>>>> - end of pipeline execution
>>>> - end of processing
>>>> That would allow e.g. a flowscript to register a listener that 
>>>> closes a hibernate session once the processing is terminated, thus 
>>>> allowing the same session to be used in the view.
>>> I believe this is already possible with the JXTemplate callback hook:
>>>     catch (return) {session.close ()}
>>> though there does seem to be a lot of confusion about it and the 
>>> syntax is strange ;)
>> I think those listeners are not only for flowscript, but more generic 
>> approach. Btw, sendPageAndWait also has a provision for clean up 
>> function. Problem is it does not work each time [1].
>> Vadim
>> [1]
> There is also a problem that sendPageAndWait doesn't wait for the view 
> generation to be finished. So if you close your hibernate session in 
> the cleanup function you will likely get lazy fetching exceptions.
> Or has this been fixed maybe?

My understanding was that sendPage now exits *after* view generation is 
done, and sendPageAndWait is just wrapper around sendPage method.

> Is there a possibility to provide a clean-up function for sendPage ( 
> same scenario as with sendPageAndWait - should wait for view to finish 
> rendering)?

Just put clean up code after sendPage(), IIRC, it will be executed after 
view generation is complete.


View raw message