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 13:42:02 GMT
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.

> 
> >  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 have now
> >> implemented a new approach were we have both a Fragment object and
> >> ContentFragment along with mathcing Page and ContentPage objects.
> >> The ContentFragment interface extends Fragment and the current
> >> ContentFragmentImpl implementation is really just a thin,
> >> per-request wrapper around the actual Fragment.  I have moved the
> >> getRenderedContent(), setPortletContent() and overrideContent()
> >> methods down into ContentFragment as the Fragment itself should
> >> never be conerned with rendered content.
> >
> >
> Im -1 on changing the Jetspeed API for this.
> Application should call getPage, not getContentPage
> It muddies the API, and confuses the application developer as to which
> API to call.
> 
> Can we refactor this so that there is only one public API, getPage, and
> keep the content concept down in the implementation? (likewise for
> fragments)
> 
>    -                Page page = pageManager.getPage(currentPage);
>    +                Page page = pageManager.getContentPage(currentPage);

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.

Regards,
Scott

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