Well, Tapestry will automatically clean up the services for you, but if you are using them inside a servlet filter (which kicks in before the Tapestry stuff), then you will have to do the cleanup yourself (or use a tapestry WebRequestServicerFilter or a ServletRequestServicerFilter and avoid the cleanup).
-----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of hv @ Fashion Content Sent: Monday, July 10, 2006 9:16 PM To: users@tapestry.apache.org Subject: Re: Using Discardable threaded services correctly? Oh ok. Well I don't know the first thing about how to use HiveMind filters, so I haven't changed any setup there. I need this functionality in my Tapestry pages and in a couple of custome servlets, so I implemented it as a ServletFilter. Rather than having 4 different ServletFilters, I combined them. As I understand it from the HiveMind docs it is my responsibility to clean up threaded services. Is that not still the case? Henrik "James Carman" <[EMAIL PROTECTED]> skrev i en meddelelse news:[EMAIL PROTECTED] >I was thinking of a Tapestry WebRequestServicerFilter or > ServletRequestServicerFilter. That basically takes the place of a servlet > filter. For the tapestry-acegi module, I actually implemented support for > regular servlet filters in the ServletRequestServicerFilter chain. I did > that because all of the Acegi stuff is implemented using various servlet > filters. > > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of hv @ Fashion Content > Sent: Monday, July 10, 2006 9:02 PM > To: users@tapestry.apache.org > Subject: Re: Using Discardable threaded services correctly? > > context.getAttribute("org.apache.tapestry.Registry:portalapp"); > PersonalIdentity ident = (PersonalIdentity) > firstRegistry.getService(PersonalIdentity.class); > > I wrote the filter and tried to incorporate all the standard functionality > needed by Tapestry, Spring & HiveMind. > > The filter essentially replaces HTTP Session management so I can't really > use the Tapestry filter. The relevant part of the code is below(and in the > original mail). > > The Tapestry filter you refer to is the redirect filter right? I don't see > any code in it relating to service cleanup. Or are you thinking of > HiveMind > filter? > > Henrik > > "James Carman" <[EMAIL PROTECTED]> skrev i en meddelelse > news:[EMAIL PROTECTED] >> How are you accessing the service in your servlet filter? Did you write >> the >> servlet filter? Why can't you use the tapestry filter mechanism? >> >> -----Original Message----- >> From: news [mailto:[EMAIL PROTECTED] On Behalf Of hv @ Fashion Content >> Sent: Monday, July 10, 2006 8:39 PM >> To: users@tapestry.apache.org >> Subject: Re: Using Discardable threaded services correctly? >> >> Since I use the service in every page of my app I have no doubt it will >> be >> instantiated. Also it's accessed in the first part of the filter. >> I think there might be something spooky going on with logging, althought >> that would be the first time I have experienced logging >> statements/internal >> errors just being eaten. >> When I removed the comment the service.threadDidDiscardService threw a >> nullpointer exception in the logging statement, indicating that the >> static >> logger variable was null..... Very odd. >> >> Henrik >> "James Carman" <[EMAIL PROTECTED]> skrev i en meddelelse >> news:[EMAIL PROTECTED] >>> HiveMind will not instantiate your service unless it is needed (which >>> would >>> explain why you saw the expected behavior after you called a method). >>> If >>> it >>> instantiates it, then it'll clean it up. >>> >>> -----Original Message----- >>> From: news [mailto:[EMAIL PROTECTED] On Behalf Of hv @ Fashion Content >>> Sent: Monday, July 10, 2006 7:55 PM >>> To: users@tapestry.apache.org >>> Subject: Using Discardable threaded services correctly? >>> >>> I have a ServletFilter which sets up an identity object for each >>> request. >>> Previously it was stored with setAttribute, but now I use a threaded >>> HiveMind service. So far it has worked just fine, but I can't seem to >>> get >>> the _Discardable_ functionality to work properly. >>> >>> PersonalIdentity extends Discardable. The first step I tried was to >>> insert >> >>> a >>> >>> logging statement in void threadDidDiscardService(). >>> >>> Nothing happened! >>> >>> Eventually I tried to just call a function on PersonalIdentity, which >>> seemed >>> >>> to work, and moreover it now threadDidDiscardService got called. >>> >>> Does Tapestry do some threaded housecleaning in ApplicationServlet? >>> >>> I suppose that I am missing something obvious, or just making a basic >>> blunder. But which one? >>> >>> Thanks, >>> Henrik >>> >>> The filter looks something like this: >>> >>> try { >>> if (firstRegistry == null) { >>> firstRegistry = (Registry) >>> context.getAttribute("org.apache.tapestry.Registry:portalapp"); >>> } >>> if (firstRegistry != null) { >>> logger.debug("Pushed PersonalIdentity to registry >>> "+firstRegistry.hashCode()); >>> PersonalIdentity ident = (PersonalIdentity) >>> firstRegistry.getService(PersonalIdentity.class); >>> ... >>> } >>> >>> chain.doFilter(req,res); >>> } >>> finally { >>> if (firstRegistry != null) { >>> // PersonalIdentity ident = (PersonalIdentity) >>> firstRegistry.getService(PersonalIdentity.class); >>> // ident.saveChanges(); >>> // ident = null; >>> firstRegistry.cleanupThread(); >>> } >>> long processingTime = System.currentTimeMillis() - startTime; >>> webApp.publishEvent(new RequestHandledEvent( >>> this,req.getRequestURI(),processingTime,req.getRemoteAddr(), >>> req.getMethod(),null >>> )); >>> } >>> >>> The registration for ident is: >>> >>> <service-point id="Identity" >>> interface="com.bluprinted.personal.market.PersonalIdentity"> >>> >>> <invoke-factory model="threaded"> >>> >>> <construct >>> class="com.bluprinted.personal.market.PersonalIdentityImpl"></construct> >>> >>> </invoke-factory> >>> >>> </service-point> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> 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] >>> >>> >> >> >> >> >> --------------------------------------------------------------------- >> 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] >> >> > > > > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- 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]
