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
[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

View raw message