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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > >> > > >> > > >>> It sounds like a servlet listener method could > > work > > >>> for you. Or a > > >>> servlet filter as in the previous suggestion. > > Both > > >>> would give you a > > >>> hook into the end-of-request, and you can get > to > > the > > >>> Visit via the > > >>> session. Here's a listener approach. > > >>> > > >>> > > >>> public class EventListener implements > > >>> ServletRequestListener > > >>> { > > >>> public void > > >>> requestInitialized(ServletRequestEvent sre) { > > >>> // This method might not need to do > > >>> anything. > > >>> } > > >>> > > >>> public void > > requestDestroyed(ServletRequestEvent > > >>> sre) > > >>> { > > >>> // Call a static method in your > > >>> thread-storage class to get your > > >>> data. > > >>> > > >>> // The slightly messy part is getting > > the > > >>> Visit from the session. > > >>> HttpSession session = > > >>> sre.getServletRequest().getSession(false); > > >>> String visitKey = "state:" + appName + > > >>> ":visit"; > > >>> Visit visit = (Visit) > > >>> session.getAttribute(visitKey); > > >>> } > > >>> } > > >>> > > >>> In your web.xml: > > >>> > > >>> <listener> > > >>> > > >>> > > >>> > > >> > > > <listener-class>your.package.EventListener</listener-class> > > >> > > >>> </listener> > > >>> > > >>> > > >>> Dobrin Ivanov wrote: > > >>> > > >>>> I have designed some small API in order to > > provide > > >>>> > > >>> the > > >>> > > >>>> session persistance of the presentation layer > > >>>> (Tapestry - Visit object/HttpSession) to the > > model > > >>>> layer (in order to be able to cache some > > session > > >>>> related stuff without being aware of how the > > above > > >>>> layer is doing it). So the data is attached > to > > the > > >>>> thread and at the end of the request cycle I > > want > > >>>> > > >>> to > > >>> > > >>>> save it into the Visit object. > > >>>> > > >>>> --- Martin Strand <[EMAIL PROTECTED]> > > wrote: > > >>>> > > >>>> > > >>>> > > >>>>> Exactly what do you need this for? > > >>>>> If you don't need any Tapestry logic, there > > might > > >>>>> > > >>> be > > >>> > > >>>>> other ways to do it - > > >>>>> like a servlet filter or a threaded service > > that > > >>>>> implements Discardable. > > >>>>> > > >>>>> On Tue, 19 Sep 2006 21:58:20 +0200, Jesse > > Kuhnert > > >>>>> <[EMAIL PROTECTED]> > > >>>>> wrote: > > >>>>> > > >>>>> > > >>>>> > > >>>>>> It might not be super fun to learn, but I > > think > > >>>>>> > > >>>>>> > > >>>>> the "tapestry" way of > > >>>>> > > >>>>> > > >>>>>> doing > > >>>>>> this would be to contribute something to > the > > >>>>>> > > >>>>>> > > >>>>> WebRequestServicerPipeline > > >>>>> > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
