You can plugin to the webrequest servicer pipeline.
> Ummm... you could do that too. You're correct that it would avoid the
> visit-from-session inelegant bit. It would be conceptually similar to
> the servlet filter approach. The downside would be that custom Engine
> classes are frowned upon as Tapestry goes forward. I'm not sure there
> is an Engine.getVisit() in 4.1.
>
> None of the approaches is perfect since Tapestry doesn't provide a
> built-in end-of-request hook. Well, there is a call to
> monitor.serviceEnd() that you could use without subclassing Engine.
>
>
> Dobrin Ivanov wrote:
>> Hi,
>> Thanks Bryan, this looks like a hack:)
>>
>> What do you think if I override the Engine's method:
>>
>> public void service(WebRequest request, WebResponse
>> response) throws IOException {
>> super.service(request, response);
>> // insert code here
>> }
>>
>> Is this a bad approach?
>>
>>
>> --- Bryan Lewis <[EMAIL PROTECTED]> wrote:
>>
>>
>>> It sounds like a servlet listener method could work
>>> for you. Or a
>>> servlet filter as in the previous suggestion. Both
>>> would give you a
>>> hook into the end-of-request, and you can get to the
>>> Visit via the
>>> session. Here's a listener approach.
>>>
>>>
>>> public class EventListener implements
>>> ServletRequestListener
>>> {
>>> public void
>>> requestInitialized(ServletRequestEvent sre) {
>>> // This method might not need to do
>>> anything.
>>> }
>>>
>>> public void requestDestroyed(ServletRequestEvent
>>> sre)
>>> {
>>> // Call a static method in your
>>> thread-storage class to get your
>>> data.
>>>
>>> // The slightly messy part is getting the
>>> Visit from the session.
>>> HttpSession session =
>>> sre.getServletRequest().getSession(false);
>>> String visitKey = "state:" + appName +
>>> ":visit";
>>> Visit visit = (Visit)
>>> session.getAttribute(visitKey);
>>> }
>>> }
>>>
>>> In your web.xml:
>>>
>>> <listener>
>>>
>>>
>>>
>> <listener-class>your.package.EventListener</listener-class>
>>
>>> </listener>
>>>
>>>
>>> Dobrin Ivanov wrote:
>>>
>>>> I have designed some small API in order to provide
>>>>
>>> the
>>>
>>>> session persistance of the presentation layer
>>>> (Tapestry - Visit object/HttpSession) to the model
>>>> layer (in order to be able to cache some session
>>>> related stuff without being aware of how the above
>>>> layer is doing it). So the data is attached to the
>>>> thread and at the end of the request cycle I want
>>>>
>>> to
>>>
>>>> save it into the Visit object.
>>>>
>>>> --- Martin Strand <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>
>>>>> Exactly what do you need this for?
>>>>> If you don't need any Tapestry logic, there might
>>>>>
>>> be
>>>
>>>>> other ways to do it -
>>>>> like a servlet filter or a threaded service that
>>>>> implements Discardable.
>>>>>
>>>>> On Tue, 19 Sep 2006 21:58:20 +0200, Jesse Kuhnert
>>>>> <[EMAIL PROTECTED]>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> It might not be super fun to learn, but I think
>>>>>>
>>>>>>
>>>>> the "tapestry" way of
>>>>>
>>>>>
>>>>>> doing
>>>>>> this would be to contribute something to the
>>>>>>
>>>>>>
>>>>> WebRequestServicerPipeline
>>>>>
>>>>>
>>>>>> so
>>>>>> that you know definitively when the cycle ends
>>>>>>
>>>>>>
>>>>> regardless of what
>>>>>
>>>>>
>>>>>> services/engines are involved..
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>> http://tapestry.apache.org/tapestry4/tapestry/hivedocs/config/tapestry.request.WebRequestServicerPipeline.html
>>
>>>>
>>>>
>>>>>> On 9/19/06, Dobrin Ivanov
>>>>>>
>>>>>>
>>>>> <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I want some advise of which is the best way to
>>>>>>>
>>>>>>>
>>>>> catch
>>>>>
>>>>>
>>>>>>> the end of the request cycly. I have tried it
>>>>>>>
>>>>>>>
>>>>> using a
>>>>>
>>>>>
>>>>>>> PageDetachListener, but the problem is that
>>>>>>>
>>>>>>>
>>>>> sometimes
>>>>>
>>>>>
>>>>>>> there is more than one page involved into the
>>>>>>>
>>>>>>>
>>>>> request
>>>>>
>>>>>
>>>>>>> cycle and then I get more than one invocation
>>>>>>>
>>> on
>>>
>>>>>>>
>>>>>>>
>>>>> the
>>>>>
>>>>>
>>>>>>> pageDetached(...).
>>>>>>> So I'm wondering if overriding the Engine's
>>>>>>> service(...) method is the best place?
>>>>>>>
>>>>>>> Thanks and best regards,
>>>>>>> Dobrin
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>>
>>>>
>>>>
>>>>> To unsubscribe, e-mail:
>>>>> [EMAIL PROTECTED]
>>>>> For additional commands, e-mail:
>>>>> [EMAIL PROTECTED]
>>>>>
>>>>>
>>>>>
>>>>>
>>>> __________________________________________________
>>>> Do You Yahoo!?
>>>> Tired of spam? Yahoo! Mail has the best spam
>>>>
>>> protection around
>>>
>>>> http://mail.yahoo.com
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>
>>>> To unsubscribe, e-mail:
>>>>
>>> [EMAIL PROTECTED]
>>>
>>>> For additional commands, e-mail:
>>>>
>>> [EMAIL PROTECTED]
>>>
>>>>
>>>>
>>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
James Carman, President
Carman Consulting, Inc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
