portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott T Weaver" <scotts-jetspeed-l...@binary-designs.net>
Subject RE: [jira] Resolved: (JS2-252) Fragments retain their previous content in certain cases
Date Mon, 02 May 2005 18:14:04 GMT
Let me know when you guys plan on discussing it, I would like to be in on
that meeting.  Also, I have also started work on an AJAX api and pipeline,
we could discuss that also.

Regards,
Scott

> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Monday, May 02, 2005 1:43 PM
> To: Jetspeed Developers List
> Subject: Re: [jira] Resolved: (JS2-252) Fragments retain their previous
> content in certain cases
> 
> 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



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