You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dobrin Ivanov <do...@yahoo.com> on 2006/09/19 21:53:10 UTC

How to listent for the Request Cycle End

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


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: How to listent for the Request Cycle End

Posted by James Carman <ja...@carmanconsulting.com>.
With this approach, you don't need a custom engine.  It really works just
like a servlet filter.

> I have used a custom engine for displaying images as is described in
> "Enjoy
> Web development with Tapestry". Is there an alternative (better) way of
> doing this?
>
> Cheers,
>
> On 9/20/06, James Carman <ja...@carmanconsulting.com> wrote:
>>
>> To plug into the WebRequestServicerPipeline, you implement the
>> WebRequestServicerFilter interface:
>>
>> public class MyFilter implements WebRequestServicerFilter
>> {
>> }
>>
>> Then, in your hivemodule.xml you plug it into the pipeline:
>>
>> <contribution
>> configuration-id="hivemind.request.WebRequestServicerPipeline">
>>   <filter name="MyFilter" object="instance:MyFilter" />
>> </contribution>
>>
>> That's off the top of my head, but you get the idea.  This basically
>> acts
>> like a servlet filter, but you can plug hivemind-managed filters in (so
>> you
>> can inject stuff into your implementation objects).
>>
>>
>> -----Original Message-----
>> From: Dobrin Ivanov [mailto:dobrin_s_ivanov@yahoo.com]
>> Sent: Wednesday, September 20, 2006 1:30 PM
>> To: Tapestry users
>> Subject: Re: How to listent for the Request Cycle End
>>
>> I do not know about this custom Engine classes changes
>> (frowned)...
>>   is there some information about this topic?
>>
>> .. and also the other one with the
>> pipelines/WebRequestServicerPipeline/interceptors?
>>
>> --- James Carman <ja...@carmanconsulting.com> wrote:
>>
>> > 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 <br...@maine.rr.com> 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 <ma...@entcap.se>
>> > 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
>> > >>>>> <jk...@gmail.com>
>> > >>>>> 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.reque
>> st.WebRequestServicerPipeline.html
>> > >>
>> > >>>>
>> > >>>>
>> > >>>>>> On 9/19/06, Dobrin Ivanov
>> > >>>>>>
>> > >>>>>>
>> > >>>>> <do...@yahoo.com> 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
>> >
>> === message truncated ===
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>


James Carman, President
Carman Consulting, Inc.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: How to listent for the Request Cycle End

Posted by Hajaansh <ha...@googlemail.com>.
I have used a custom engine for displaying images as is described in "Enjoy
Web development with Tapestry". Is there an alternative (better) way of
doing this?

Cheers,

On 9/20/06, James Carman <ja...@carmanconsulting.com> wrote:
>
> To plug into the WebRequestServicerPipeline, you implement the
> WebRequestServicerFilter interface:
>
> public class MyFilter implements WebRequestServicerFilter
> {
> }
>
> Then, in your hivemodule.xml you plug it into the pipeline:
>
> <contribution
> configuration-id="hivemind.request.WebRequestServicerPipeline">
>   <filter name="MyFilter" object="instance:MyFilter" />
> </contribution>
>
> That's off the top of my head, but you get the idea.  This basically acts
> like a servlet filter, but you can plug hivemind-managed filters in (so
> you
> can inject stuff into your implementation objects).
>
>
> -----Original Message-----
> From: Dobrin Ivanov [mailto:dobrin_s_ivanov@yahoo.com]
> Sent: Wednesday, September 20, 2006 1:30 PM
> To: Tapestry users
> Subject: Re: How to listent for the Request Cycle End
>
> I do not know about this custom Engine classes changes
> (frowned)...
>   is there some information about this topic?
>
> .. and also the other one with the
> pipelines/WebRequestServicerPipeline/interceptors?
>
> --- James Carman <ja...@carmanconsulting.com> wrote:
>
> > 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 <br...@maine.rr.com> 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 <ma...@entcap.se>
> > 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
> > >>>>> <jk...@gmail.com>
> > >>>>> 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.reque
> st.WebRequestServicerPipeline.html
> > >>
> > >>>>
> > >>>>
> > >>>>>> On 9/19/06, Dobrin Ivanov
> > >>>>>>
> > >>>>>>
> > >>>>> <do...@yahoo.com> 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
> >
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: How to listent for the Request Cycle End

Posted by Dobrin Ivanov <do...@yahoo.com>.
Cool :) 
Thanks a lot, it works for me too :)

It seems that the documentation is poor or I am not
searching at the right place..?

--- Bryan Lewis <br...@maine.rr.com> wrote:

> I believe the reason the WebRequestServicerFilter
> was suggested was to
> avoid that inelegant bit.  This worked for me:
> 
>   <service-point id="WebRequestFilter"
>
interface="org.apache.tapestry.services.WebRequestServicerFilter">
>     <invoke-factory>
>       <construct
> class="cview.services.WebRequestFilter">
>         <set-object property="appStateManager"
> value="infrastructure:applicationStateManager"/>
>       </construct>
>     </invoke-factory>
>   </service-point>
> 
>   <contribution
>
configuration-id="tapestry.request.WebRequestServicerPipeline">
>     <filter name="WebRequestFilter"
> object="service:WebRequestFilter" />
>   </contribution>
> 
> public class WebRequestFilter implements
> WebRequestServicerFilter {
>     private ApplicationStateManager appStateManager;
>     public void
> setAppStateManager(ApplicationStateManager asm) {
>         appStateManager = asm;
>     }
> 
>     public void service(....)  {
>         servicer.service(request, response);
>         System.out.println("visit = " + (Visit)
> appStateManager.get("visit"));
>     }
> }
> 
> 
> Dobrin Ivanov wrote:
> > Thanks, now it works. My filter is :
> > -----------------------------------------
> > public void service(WebRequest request,
> WebResponse
> > response, WebRequestServicer servicer) throws
> > IOException { 
> >   // Request Cycle Begin
> >   servicer.service(request, response);
> >   // Request Cycle End
> >   WebSession webSession =
> request.getSession(false);
> >   if (webSession!=null) {
> >     String visitKey = "state:" + APP_NAME +
> ":visit";
> >     Visit visit = (Visit)
> > webSession.getAttribute(visitKey); 
> >     // use visit
> >   }
> > }
> > -----------------------------------------
> >
> > So, we again have this visit-from-session code,
> but
> > the only inelegant bit is this visitKey assembling
> > part may be :)
> >
> > --- James Carman <ja...@carmanconsulting.com>
> wrote:
> >
> >   
> >> Sorry.  Try
> >> tapestry.request.WebRequestServicerPipeline.  As
> I
> >> said, it was
> >> off the top of my head.  Sorry for the typo.
> >>
> >> -----Original Message-----
> >> From: Dobrin Ivanov
> >> [mailto:dobrin_s_ivanov@yahoo.com] 
> >> Sent: Friday, September 22, 2006 1:45 PM
> >> To: Tapestry users
> >> Subject: RE: How to listent for the Request Cycle
> >> End
> >>
> >> 10x
> >>
> >> Now i get the error below. Any chance that there
> are
> >> some docs for this?
> >>
> >> 1547 [main] ERROR
> >>
> >>     
> >
>
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/weprom]
> >   
> >>  - Servlet /weprom threw load() exception
> >> org.apache.hivemind.ApplicationRuntimeException:
> >> Error
> >> at context:/WEB-INF/hivemodule.xml, line 19,
> column
> >> 79: Module weprom has contributed to unknown con
> >> figuration point
> >> hivemind.request.WebRequestServicerPipeline. The
> >> contribution has been ignored.
> >> [context:/WEB-INF/hivemodule.xml, line 19, column
> >> 79]
> >>         at
> >>
> >>     
> >
>
org.apache.hivemind.impl.StrictErrorHandler.error(StrictErrorHandler.java:39
> >   
> >> )
> >>
> >> --- James Carman <ja...@carmanconsulting.com>
> wrote:
> >>
> >>     
> >>> You can put it in your WEB-INF folder or in
> >>> WEB-INF/classes/META-INF.
> >>> Tapestry (actually HiveMind) will find it in
> >>>       
> >> either
> >>     
> >>> case.
> >>>
> >>> -----Original Message-----
> >>> From: Dobrin Ivanov
> >>> [mailto:dobrin_s_ivanov@yahoo.com] 
> >>> Sent: Friday, September 22, 2006 1:26 PM
> >>> To: Tapestry users
> >>> Subject: RE: How to listent for the Request
> Cycle
> >>> End
> >>>
> >>> And where should be located my hivemodule.xml?
> >>>       
> >> (I'm
> >>     
> >>> using just Tapestry, I know it lies above
> hivemind
> >>> microkernel...)
> >>>
> >>>
> >>> --- James Carman <ja...@carmanconsulting.com>
> >>>       
> >> wrote:
> >>     
> >>>> To plug into the WebRequestServicerPipeline,
> you
> >>>> implement the
> >>>> WebRequestServicerFilter interface:
> >>>>
> >>>> public class MyFilter implements
> >>>> WebRequestServicerFilter
> >>>> {
> >>>> }
> >>>>
> >>>> Then, in your hivemodule.xml you plug it into
> >>>>         
> >> the
> >>     
> >>>> pipeline:
> >>>>
> >>>> <contribution
> >>>>
> >>>>         
> >
>
configuration-id="hivemind.request.WebRequestServicerPipeline">
> >   
> >>>>   <filter name="MyFilter"
> >>>>         
> >>> object="instance:MyFilter"
> >>>       
> >>>> />
> >>>> </contribution>
> >>>>
> >>>> That's off the top of my head, but you get the
> >>>>         
> >>> idea.
> >>>       
> >>>>  This basically acts
> >>>> like a servlet filter, but you can plug
> >>>> hivemind-managed filters in (so you
> >>>> can inject stuff into your implementation
> >>>>         
> >>> objects).
> >>>       
> >>>> -----Original Message-----
> >>>> From: Dobrin Ivanov
> >>>> [mailto:dobrin_s_ivanov@yahoo.com] 
> >>>> Sent: Wednesday, September 20, 2006 1:30 PM
> >>>> To: Tapestry users
> >>>> Subject: Re: How to listent for the Request
> >>>>         
> >> Cycle
> >>     
> >>>> End
> >>>>
> >>>> I do not know about this custom Engine classes
> >>>> changes
> >>>> (frowned)... 
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: How to listent for the Request Cycle End

Posted by Bryan Lewis <br...@maine.rr.com>.
I believe the reason the WebRequestServicerFilter was suggested was to
avoid that inelegant bit.  This worked for me:

  <service-point id="WebRequestFilter"
interface="org.apache.tapestry.services.WebRequestServicerFilter">
    <invoke-factory>
      <construct class="cview.services.WebRequestFilter">
        <set-object property="appStateManager"
value="infrastructure:applicationStateManager"/>
      </construct>
    </invoke-factory>
  </service-point>

  <contribution
configuration-id="tapestry.request.WebRequestServicerPipeline">
    <filter name="WebRequestFilter" object="service:WebRequestFilter" />
  </contribution>

public class WebRequestFilter implements WebRequestServicerFilter {
    private ApplicationStateManager appStateManager;
    public void setAppStateManager(ApplicationStateManager asm) {
        appStateManager = asm;
    }

    public void service(....)  {
        servicer.service(request, response);
        System.out.println("visit = " + (Visit)
appStateManager.get("visit"));
    }
}


Dobrin Ivanov wrote:
> Thanks, now it works. My filter is :
> -----------------------------------------
> public void service(WebRequest request, WebResponse
> response, WebRequestServicer servicer) throws
> IOException { 
>   // Request Cycle Begin
>   servicer.service(request, response);
>   // Request Cycle End
>   WebSession webSession = request.getSession(false);
>   if (webSession!=null) {
>     String visitKey = "state:" + APP_NAME + ":visit";
>     Visit visit = (Visit)
> webSession.getAttribute(visitKey); 
>     // use visit
>   }
> }
> -----------------------------------------
>
> So, we again have this visit-from-session code, but
> the only inelegant bit is this visitKey assembling
> part may be :)
>
> --- James Carman <ja...@carmanconsulting.com> wrote:
>
>   
>> Sorry.  Try
>> tapestry.request.WebRequestServicerPipeline.  As I
>> said, it was
>> off the top of my head.  Sorry for the typo.
>>
>> -----Original Message-----
>> From: Dobrin Ivanov
>> [mailto:dobrin_s_ivanov@yahoo.com] 
>> Sent: Friday, September 22, 2006 1:45 PM
>> To: Tapestry users
>> Subject: RE: How to listent for the Request Cycle
>> End
>>
>> 10x
>>
>> Now i get the error below. Any chance that there are
>> some docs for this?
>>
>> 1547 [main] ERROR
>>
>>     
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/weprom]
>   
>>  - Servlet /weprom threw load() exception
>> org.apache.hivemind.ApplicationRuntimeException:
>> Error
>> at context:/WEB-INF/hivemodule.xml, line 19, column
>> 79: Module weprom has contributed to unknown con
>> figuration point
>> hivemind.request.WebRequestServicerPipeline. The
>> contribution has been ignored.
>> [context:/WEB-INF/hivemodule.xml, line 19, column
>> 79]
>>         at
>>
>>     
> org.apache.hivemind.impl.StrictErrorHandler.error(StrictErrorHandler.java:39
>   
>> )
>>
>> --- James Carman <ja...@carmanconsulting.com> wrote:
>>
>>     
>>> You can put it in your WEB-INF folder or in
>>> WEB-INF/classes/META-INF.
>>> Tapestry (actually HiveMind) will find it in
>>>       
>> either
>>     
>>> case.
>>>
>>> -----Original Message-----
>>> From: Dobrin Ivanov
>>> [mailto:dobrin_s_ivanov@yahoo.com] 
>>> Sent: Friday, September 22, 2006 1:26 PM
>>> To: Tapestry users
>>> Subject: RE: How to listent for the Request Cycle
>>> End
>>>
>>> And where should be located my hivemodule.xml?
>>>       
>> (I'm
>>     
>>> using just Tapestry, I know it lies above hivemind
>>> microkernel...)
>>>
>>>
>>> --- James Carman <ja...@carmanconsulting.com>
>>>       
>> wrote:
>>     
>>>> To plug into the WebRequestServicerPipeline, you
>>>> implement the
>>>> WebRequestServicerFilter interface:
>>>>
>>>> public class MyFilter implements
>>>> WebRequestServicerFilter
>>>> {
>>>> }
>>>>
>>>> Then, in your hivemodule.xml you plug it into
>>>>         
>> the
>>     
>>>> pipeline:
>>>>
>>>> <contribution
>>>>
>>>>         
> configuration-id="hivemind.request.WebRequestServicerPipeline">
>   
>>>>   <filter name="MyFilter"
>>>>         
>>> object="instance:MyFilter"
>>>       
>>>> />
>>>> </contribution>
>>>>
>>>> That's off the top of my head, but you get the
>>>>         
>>> idea.
>>>       
>>>>  This basically acts
>>>> like a servlet filter, but you can plug
>>>> hivemind-managed filters in (so you
>>>> can inject stuff into your implementation
>>>>         
>>> objects).
>>>       
>>>> -----Original Message-----
>>>> From: Dobrin Ivanov
>>>> [mailto:dobrin_s_ivanov@yahoo.com] 
>>>> Sent: Wednesday, September 20, 2006 1:30 PM
>>>> To: Tapestry users
>>>> Subject: Re: How to listent for the Request
>>>>         
>> Cycle
>>     
>>>> End
>>>>
>>>> I do not know about this custom Engine classes
>>>> changes
>>>> (frowned)... 
>>>>   is there some information about this topic? 
>>>>
>>>> .. and also the other one with the
>>>>
>>>>         
>> pipelines/WebRequestServicerPipeline/interceptors?
>>     
>>>> --- James Carman <ja...@carmanconsulting.com>
>>>>         
>>> wrote:
>>>       
>>>>> 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 <br...@maine.rr.com> 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.
>>>>>>>>                 
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>   


RE: How to listent for the Request Cycle End

Posted by Dobrin Ivanov <do...@yahoo.com>.
Thanks, now it works. My filter is :
-----------------------------------------
public void service(WebRequest request, WebResponse
response, WebRequestServicer servicer) throws
IOException { 
  // Request Cycle Begin
  servicer.service(request, response);
  // Request Cycle End
  WebSession webSession = request.getSession(false);
  if (webSession!=null) {
    String visitKey = "state:" + APP_NAME + ":visit";
    Visit visit = (Visit)
webSession.getAttribute(visitKey); 
    // use visit
  }
}
-----------------------------------------

So, we again have this visit-from-session code, but
the only inelegant bit is this visitKey assembling
part may be :)

--- James Carman <ja...@carmanconsulting.com> wrote:

> Sorry.  Try
> tapestry.request.WebRequestServicerPipeline.  As I
> said, it was
> off the top of my head.  Sorry for the typo.
> 
> -----Original Message-----
> From: Dobrin Ivanov
> [mailto:dobrin_s_ivanov@yahoo.com] 
> Sent: Friday, September 22, 2006 1:45 PM
> To: Tapestry users
> Subject: RE: How to listent for the Request Cycle
> End
> 
> 10x
> 
> Now i get the error below. Any chance that there are
> some docs for this?
> 
> 1547 [main] ERROR
>
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/weprom]
>  - Servlet /weprom threw load() exception
> org.apache.hivemind.ApplicationRuntimeException:
> Error
> at context:/WEB-INF/hivemodule.xml, line 19, column
> 79: Module weprom has contributed to unknown con
> figuration point
> hivemind.request.WebRequestServicerPipeline. The
> contribution has been ignored.
> [context:/WEB-INF/hivemodule.xml, line 19, column
> 79]
>         at
>
org.apache.hivemind.impl.StrictErrorHandler.error(StrictErrorHandler.java:39
> )
> 
> --- James Carman <ja...@carmanconsulting.com> wrote:
> 
> > You can put it in your WEB-INF folder or in
> > WEB-INF/classes/META-INF.
> > Tapestry (actually HiveMind) will find it in
> either
> > case.
> > 
> > -----Original Message-----
> > From: Dobrin Ivanov
> > [mailto:dobrin_s_ivanov@yahoo.com] 
> > Sent: Friday, September 22, 2006 1:26 PM
> > To: Tapestry users
> > Subject: RE: How to listent for the Request Cycle
> > End
> > 
> > And where should be located my hivemodule.xml?
> (I'm
> > using just Tapestry, I know it lies above hivemind
> > microkernel...)
> > 
> > 
> > --- James Carman <ja...@carmanconsulting.com>
> wrote:
> > 
> > > To plug into the WebRequestServicerPipeline, you
> > > implement the
> > > WebRequestServicerFilter interface:
> > > 
> > > public class MyFilter implements
> > > WebRequestServicerFilter
> > > {
> > > }
> > > 
> > > Then, in your hivemodule.xml you plug it into
> the
> > > pipeline:
> > > 
> > > <contribution
> > >
> >
>
configuration-id="hivemind.request.WebRequestServicerPipeline">
> > >   <filter name="MyFilter"
> > object="instance:MyFilter"
> > > />
> > > </contribution>
> > > 
> > > That's off the top of my head, but you get the
> > idea.
> > >  This basically acts
> > > like a servlet filter, but you can plug
> > > hivemind-managed filters in (so you
> > > can inject stuff into your implementation
> > objects).
> > > 
> > > 
> > > -----Original Message-----
> > > From: Dobrin Ivanov
> > > [mailto:dobrin_s_ivanov@yahoo.com] 
> > > Sent: Wednesday, September 20, 2006 1:30 PM
> > > To: Tapestry users
> > > Subject: Re: How to listent for the Request
> Cycle
> > > End
> > > 
> > > I do not know about this custom Engine classes
> > > changes
> > > (frowned)... 
> > >   is there some information about this topic? 
> > > 
> > > .. and also the other one with the
> > >
> pipelines/WebRequestServicerPipeline/interceptors?
> > > 
> > > --- James Carman <ja...@carmanconsulting.com>
> > wrote:
> > > 
> > > > 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 <br...@maine.rr.com> 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.
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


RE: How to listent for the Request Cycle End

Posted by James Carman <ja...@carmanconsulting.com>.
Sorry.  Try tapestry.request.WebRequestServicerPipeline.  As I said, it was
off the top of my head.  Sorry for the typo.

-----Original Message-----
From: Dobrin Ivanov [mailto:dobrin_s_ivanov@yahoo.com] 
Sent: Friday, September 22, 2006 1:45 PM
To: Tapestry users
Subject: RE: How to listent for the Request Cycle End

10x

Now i get the error below. Any chance that there are
some docs for this?

1547 [main] ERROR
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/weprom]
 - Servlet /weprom threw load() exception
org.apache.hivemind.ApplicationRuntimeException: Error
at context:/WEB-INF/hivemodule.xml, line 19, column
79: Module weprom has contributed to unknown con
figuration point
hivemind.request.WebRequestServicerPipeline. The
contribution has been ignored.
[context:/WEB-INF/hivemodule.xml, line 19, column 79]
        at
org.apache.hivemind.impl.StrictErrorHandler.error(StrictErrorHandler.java:39
)

--- James Carman <ja...@carmanconsulting.com> wrote:

> You can put it in your WEB-INF folder or in
> WEB-INF/classes/META-INF.
> Tapestry (actually HiveMind) will find it in either
> case.
> 
> -----Original Message-----
> From: Dobrin Ivanov
> [mailto:dobrin_s_ivanov@yahoo.com] 
> Sent: Friday, September 22, 2006 1:26 PM
> To: Tapestry users
> Subject: RE: How to listent for the Request Cycle
> End
> 
> And where should be located my hivemodule.xml? (I'm
> using just Tapestry, I know it lies above hivemind
> microkernel...)
> 
> 
> --- James Carman <ja...@carmanconsulting.com> wrote:
> 
> > To plug into the WebRequestServicerPipeline, you
> > implement the
> > WebRequestServicerFilter interface:
> > 
> > public class MyFilter implements
> > WebRequestServicerFilter
> > {
> > }
> > 
> > Then, in your hivemodule.xml you plug it into the
> > pipeline:
> > 
> > <contribution
> >
>
configuration-id="hivemind.request.WebRequestServicerPipeline">
> >   <filter name="MyFilter"
> object="instance:MyFilter"
> > />
> > </contribution>
> > 
> > That's off the top of my head, but you get the
> idea.
> >  This basically acts
> > like a servlet filter, but you can plug
> > hivemind-managed filters in (so you
> > can inject stuff into your implementation
> objects).
> > 
> > 
> > -----Original Message-----
> > From: Dobrin Ivanov
> > [mailto:dobrin_s_ivanov@yahoo.com] 
> > Sent: Wednesday, September 20, 2006 1:30 PM
> > To: Tapestry users
> > Subject: Re: How to listent for the Request Cycle
> > End
> > 
> > I do not know about this custom Engine classes
> > changes
> > (frowned)... 
> >   is there some information about this topic? 
> > 
> > .. and also the other one with the
> > pipelines/WebRequestServicerPipeline/interceptors?
> > 
> > --- James Carman <ja...@carmanconsulting.com>
> wrote:
> > 
> > > 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 <br...@maine.rr.com> 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
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


RE: How to listent for the Request Cycle End

Posted by Dobrin Ivanov <do...@yahoo.com>.
10x

Now i get the error below. Any chance that there are
some docs for this?

1547 [main] ERROR
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/weprom]
 - Servlet /weprom threw load() exception
org.apache.hivemind.ApplicationRuntimeException: Error
at context:/WEB-INF/hivemodule.xml, line 19, column
79: Module weprom has contributed to unknown con
figuration point
hivemind.request.WebRequestServicerPipeline. The
contribution has been ignored.
[context:/WEB-INF/hivemodule.xml, line 19, column 79]
        at
org.apache.hivemind.impl.StrictErrorHandler.error(StrictErrorHandler.java:39)

--- James Carman <ja...@carmanconsulting.com> wrote:

> You can put it in your WEB-INF folder or in
> WEB-INF/classes/META-INF.
> Tapestry (actually HiveMind) will find it in either
> case.
> 
> -----Original Message-----
> From: Dobrin Ivanov
> [mailto:dobrin_s_ivanov@yahoo.com] 
> Sent: Friday, September 22, 2006 1:26 PM
> To: Tapestry users
> Subject: RE: How to listent for the Request Cycle
> End
> 
> And where should be located my hivemodule.xml? (I'm
> using just Tapestry, I know it lies above hivemind
> microkernel...)
> 
> 
> --- James Carman <ja...@carmanconsulting.com> wrote:
> 
> > To plug into the WebRequestServicerPipeline, you
> > implement the
> > WebRequestServicerFilter interface:
> > 
> > public class MyFilter implements
> > WebRequestServicerFilter
> > {
> > }
> > 
> > Then, in your hivemodule.xml you plug it into the
> > pipeline:
> > 
> > <contribution
> >
>
configuration-id="hivemind.request.WebRequestServicerPipeline">
> >   <filter name="MyFilter"
> object="instance:MyFilter"
> > />
> > </contribution>
> > 
> > That's off the top of my head, but you get the
> idea.
> >  This basically acts
> > like a servlet filter, but you can plug
> > hivemind-managed filters in (so you
> > can inject stuff into your implementation
> objects).
> > 
> > 
> > -----Original Message-----
> > From: Dobrin Ivanov
> > [mailto:dobrin_s_ivanov@yahoo.com] 
> > Sent: Wednesday, September 20, 2006 1:30 PM
> > To: Tapestry users
> > Subject: Re: How to listent for the Request Cycle
> > End
> > 
> > I do not know about this custom Engine classes
> > changes
> > (frowned)... 
> >   is there some information about this topic? 
> > 
> > .. and also the other one with the
> > pipelines/WebRequestServicerPipeline/interceptors?
> > 
> > --- James Carman <ja...@carmanconsulting.com>
> wrote:
> > 
> > > 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 <br...@maine.rr.com> 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
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


RE: How to listent for the Request Cycle End

Posted by James Carman <ja...@carmanconsulting.com>.
You can put it in your WEB-INF folder or in WEB-INF/classes/META-INF.
Tapestry (actually HiveMind) will find it in either case.

-----Original Message-----
From: Dobrin Ivanov [mailto:dobrin_s_ivanov@yahoo.com] 
Sent: Friday, September 22, 2006 1:26 PM
To: Tapestry users
Subject: RE: How to listent for the Request Cycle End

And where should be located my hivemodule.xml? (I'm
using just Tapestry, I know it lies above hivemind
microkernel...)


--- James Carman <ja...@carmanconsulting.com> wrote:

> To plug into the WebRequestServicerPipeline, you
> implement the
> WebRequestServicerFilter interface:
> 
> public class MyFilter implements
> WebRequestServicerFilter
> {
> }
> 
> Then, in your hivemodule.xml you plug it into the
> pipeline:
> 
> <contribution
>
configuration-id="hivemind.request.WebRequestServicerPipeline">
>   <filter name="MyFilter" object="instance:MyFilter"
> />
> </contribution>
> 
> That's off the top of my head, but you get the idea.
>  This basically acts
> like a servlet filter, but you can plug
> hivemind-managed filters in (so you
> can inject stuff into your implementation objects).
> 
> 
> -----Original Message-----
> From: Dobrin Ivanov
> [mailto:dobrin_s_ivanov@yahoo.com] 
> Sent: Wednesday, September 20, 2006 1:30 PM
> To: Tapestry users
> Subject: Re: How to listent for the Request Cycle
> End
> 
> I do not know about this custom Engine classes
> changes
> (frowned)... 
>   is there some information about this topic? 
> 
> .. and also the other one with the
> pipelines/WebRequestServicerPipeline/interceptors?
> 
> --- James Carman <ja...@carmanconsulting.com> wrote:
> 
> > 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 <br...@maine.rr.com> 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 <ma...@entcap.se>
> > 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
> > >>>>> <jk...@gmail.com>
> > >>>>> 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
> > >>>>>
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


RE: How to listent for the Request Cycle End

Posted by Dobrin Ivanov <do...@yahoo.com>.
And where should be located my hivemodule.xml? (I'm
using just Tapestry, I know it lies above hivemind
microkernel...)


--- James Carman <ja...@carmanconsulting.com> wrote:

> To plug into the WebRequestServicerPipeline, you
> implement the
> WebRequestServicerFilter interface:
> 
> public class MyFilter implements
> WebRequestServicerFilter
> {
> }
> 
> Then, in your hivemodule.xml you plug it into the
> pipeline:
> 
> <contribution
>
configuration-id="hivemind.request.WebRequestServicerPipeline">
>   <filter name="MyFilter" object="instance:MyFilter"
> />
> </contribution>
> 
> That's off the top of my head, but you get the idea.
>  This basically acts
> like a servlet filter, but you can plug
> hivemind-managed filters in (so you
> can inject stuff into your implementation objects).
> 
> 
> -----Original Message-----
> From: Dobrin Ivanov
> [mailto:dobrin_s_ivanov@yahoo.com] 
> Sent: Wednesday, September 20, 2006 1:30 PM
> To: Tapestry users
> Subject: Re: How to listent for the Request Cycle
> End
> 
> I do not know about this custom Engine classes
> changes
> (frowned)... 
>   is there some information about this topic? 
> 
> .. and also the other one with the
> pipelines/WebRequestServicerPipeline/interceptors?
> 
> --- James Carman <ja...@carmanconsulting.com> wrote:
> 
> > 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 <br...@maine.rr.com> 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 <ma...@entcap.se>
> > 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
> > >>>>> <jk...@gmail.com>
> > >>>>> 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
> > >>>>>
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


RE: How to listent for the Request Cycle End

Posted by James Carman <ja...@carmanconsulting.com>.
To plug into the WebRequestServicerPipeline, you implement the
WebRequestServicerFilter interface:

public class MyFilter implements WebRequestServicerFilter
{
}

Then, in your hivemodule.xml you plug it into the pipeline:

<contribution
configuration-id="hivemind.request.WebRequestServicerPipeline">
  <filter name="MyFilter" object="instance:MyFilter" />
</contribution>

That's off the top of my head, but you get the idea.  This basically acts
like a servlet filter, but you can plug hivemind-managed filters in (so you
can inject stuff into your implementation objects).


-----Original Message-----
From: Dobrin Ivanov [mailto:dobrin_s_ivanov@yahoo.com] 
Sent: Wednesday, September 20, 2006 1:30 PM
To: Tapestry users
Subject: Re: How to listent for the Request Cycle End

I do not know about this custom Engine classes changes
(frowned)... 
  is there some information about this topic? 

.. and also the other one with the
pipelines/WebRequestServicerPipeline/interceptors?

--- James Carman <ja...@carmanconsulting.com> wrote:

> 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 <br...@maine.rr.com> 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 <ma...@entcap.se>
> 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
> >>>>> <jk...@gmail.com>
> >>>>> 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.reque
st.WebRequestServicerPipeline.html
> >>
> >>>>
> >>>>
> >>>>>> On 9/19/06, Dobrin Ivanov
> >>>>>>
> >>>>>>
> >>>>> <do...@yahoo.com> 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
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: How to listent for the Request Cycle End

Posted by Dobrin Ivanov <do...@yahoo.com>.
I do not know about this custom Engine classes changes
(frowned)... 
  is there some information about this topic? 

.. and also the other one with the
pipelines/WebRequestServicerPipeline/interceptors?

--- James Carman <ja...@carmanconsulting.com> wrote:

> 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 <br...@maine.rr.com> 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 <ma...@entcap.se>
> 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
> >>>>> <jk...@gmail.com>
> >>>>> 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
> >>>>>>
> >>>>>>
> >>>>> <do...@yahoo.com> 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
> 
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: How to listent for the Request Cycle End

Posted by James Carman <ja...@carmanconsulting.com>.
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 <br...@maine.rr.com> 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 <ma...@entcap.se> 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
>>>>> <jk...@gmail.com>
>>>>> 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
>>>>>>
>>>>>>
>>>>> <do...@yahoo.com> 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:
>>>>> users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>> __________________________________________________
>>>> Do You Yahoo!?
>>>> Tired of spam?  Yahoo! Mail has the best spam
>>>>
>>> protection around
>>>
>>>> http://mail.yahoo.com
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>>
>>>> To unsubscribe, e-mail:
>>>>
>>> users-unsubscribe@tapestry.apache.org
>>>
>>>> For additional commands, e-mail:
>>>>
>>> users-help@tapestry.apache.org
>>>
>>>>
>>>>
>>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam?  Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>


James Carman, President
Carman Consulting, Inc.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: How to listent for the Request Cycle End

Posted by Bryan Lewis <br...@maine.rr.com>.
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 <br...@maine.rr.com> 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 <ma...@entcap.se> 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
>>>> <jk...@gmail.com>  
>>>> 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
>>>>>       
>>>>>           
>>>> <do...@yahoo.com> 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:
>>>> users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail:
>>>> users-help@tapestry.apache.org
>>>>
>>>>
>>>>     
>>>>         
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam
>>>       
>> protection around 
>>     
>>> http://mail.yahoo.com 
>>>
>>>
>>>       
> ---------------------------------------------------------------------
>   
>>> To unsubscribe, e-mail:
>>>       
>> users-unsubscribe@tapestry.apache.org
>>     
>>> For additional commands, e-mail:
>>>       
>> users-help@tapestry.apache.org
>>     
>>>   
>>>       
>>     
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>   


Re: How to listent for the Request Cycle End

Posted by Dobrin Ivanov <do...@yahoo.com>.
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 <br...@maine.rr.com> 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 <ma...@entcap.se> 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
> >> <jk...@gmail.com>  
> >> 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
> >>>       
> >> <do...@yahoo.com> 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:
> >> users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail:
> >> users-help@tapestry.apache.org
> >>
> >>
> >>     
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> > http://mail.yahoo.com 
> >
> >
>
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail:
> users-help@tapestry.apache.org
> >
> >   
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: How to listent for the Request Cycle End

Posted by Bryan Lewis <br...@maine.rr.com>.
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 <ma...@entcap.se> 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
>> <jk...@gmail.com>  
>> 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
>>>       
>> <do...@yahoo.com> 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:
>> users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail:
>> users-help@tapestry.apache.org
>>
>>
>>     
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>   


Re: How to listent for the Request Cycle End

Posted by Dobrin Ivanov <do...@yahoo.com>.
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 <ma...@entcap.se> 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
> <jk...@gmail.com>  
> 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
> <do...@yahoo.com> 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:
> users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail:
> users-help@tapestry.apache.org
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: How to listent for the Request Cycle End

Posted by Martin Strand <ma...@entcap.se>.
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 <jk...@gmail.com>  
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 <do...@yahoo.com> 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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: How to listent for the Request Cycle End

Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <do...@yahoo.com> 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
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com