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]
