portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: [jira] Resolved: (JS2-252) Fragments retain their previous content in certain cases
Date Mon, 02 May 2005 17:42:44 GMT
Scott T Weaver wrote:
> Hi David,
> 
> Sorry for the delay on my response.
> 
> 
> 
>>-----Original Message-----
>>From: David Sean Taylor [mailto:david@bluesunrise.com]
>>Sent: Friday, April 29, 2005 11:55 AM
>>To: Jetspeed Developers List
>>Subject: Re: [jira] Resolved: (JS2-252) Fragments retain their previous
>>content in certain cases
>>
>>Scott T Weaver (JIRA) wrote:
>>
>>>[ http://issues.apache.org/jira/browse/JS2-252?page=all ]
>>>
>>>Scott T Weaver resolved JS2-252: --------------------------------
>>>
>>>Resolution: Fixed
>>>
>>>
>>>
>>>>Fragments retain their previous content in certain cases
>>>>--------------------------------------------------------
>>>>
>>>>Key: JS2-252 URL: http://issues.apache.org/jira/browse/JS2-252
>>>>Project: Jetspeed 2 Type: Bug Components: Aggregation Versions:
>>>>2.0-M2 Reporter: Scott T Weaver Assignee: Scott T Weaver Priority:
>>>>Critical Fix For: 2.0-FINAL, 2.0-M2, 2.0-M3
>>>
>>>
>>>>Since Fragments are single instances of metadata, I had originally
>>>>stored rendered content in a ThreadLocal variable anticipating that
>>>>these ThreadLocals  would be attached to the application server's
>>>>request thread.  However, I started to notice strange behavior with
>>>>portlet content, espeically after redeployment.  What I saw (while
>>>>in debug) was portlet content references and overridden content
>>>>refrences for fragments where not disappearing after the request
>>>>was finished, which caused incorrect content to displayed randomly
>>>>within the portlet.
>>
>>Would it be possible to have a reset on threadlocal data?
> 
> 
> I can take a look at doing it that way if you like.  But, I feel that the
> ThreadLocal can be somewhat unpredictable, especially in asynchronous
> rendering situations.
> 

Randy and I have scheduled some time to review the entire rendering 
process together this week. Id like to invest that time in code review 
before commenting further


> 
>>> I came to the realization that the thread the
>>>
>>>>ThreadLocals were attachin was in fact the rendering job threads
>>>>and not the request threads.  This is a real issue, seeing that we
>>>>recycle the render job threads in a thread pool.
>>
>>
> 
> I could have easily done it this way originally.  The reason I changed the
> API was to make clear that the actual Fragment class is metadata only and
> therefore should not contain rendered content.  However, if you feel this is
> to confusing I can easily change it back and remove the two new interfaces.
> 

Well Im just trying to make the API as clear as possible.
To me it seems that having two APIs for the basiclly same operation will 
muddy the waters

-- 
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
[office] +01 707 773-4646
[mobile] +01 707 529 9194

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message