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 Wed, 18 May 2005 13:37:30 GMT
Thanks Ate,  I will take a look at this.

Regards,
-Scott

> -----Original Message-----
> From: Ate Douma [mailto:ate@douma.nu]
> Sent: Wednesday, May 18, 2005 6:03 AM
> To: Jetspeed Developers List
> Cc: Scott Weaver
> Subject: Re: [jira] Resolved: (JS2-252) Fragments retain their previous
> content in certain cases
> 
> Scott, I found a problem with the new ContentPageImpl: it doesn't
> implement AbstractNode.
> CastorXmlPageManager.registerPage(Page) throws a ClassCastException on
> line 1632:
> 
>          setProfiledNodePathAndUrl((AbstractNode)page);
> 
> Stacktrace from jetspeed.log:
> 
> 2005-05-18 11:46:08,015 [http-8080-Processor24] ERROR
> org.apache.jetspeed.portlets.layout.MultiColumnPortlet - Unable to update
> page /jpetstore.psml
> layout: java.lang.ClassCastException
> java.lang.ClassCastException
> 	at
> org.apache.jetspeed.page.impl.CastorXmlPageManager.registerPage(CastorXmlP
> ageManager.java:1632)
> 	at
> org.apache.jetspeed.page.impl.CastorXmlPageManager.updatePage(CastorXmlPag
> eManager.java:1658)
> 	at
> org.apache.jetspeed.portlets.layout.MultiColumnPortlet.buildColumns(MultiC
> olumnPortlet.java:240)
> 	at
> org.apache.jetspeed.portlets.layout.MultiColumnPortlet.doView(MultiColumnP
> ortlet.java:113)
> 	at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:247)
> 	at javax.portlet.GenericPortlet.render(GenericPortlet.java:175)
> 	at
> org.apache.jetspeed.factory.JetspeedPortletInstance.render(JetspeedPortlet
> Instance.java:96)
> 	at
> org.apache.jetspeed.container.invoker.LocalPortletInvoker.invoke(LocalPort
> letInvoker.java:190)
> 	at
> org.apache.jetspeed.container.invoker.LocalPortletInvoker.render(LocalPort
> letInvoker.java:116)
> 
> Because JIRA isn't save/possible to use right now I didn't dare to comment
> on the issue.
> 
> Regards, Ate
> 
> 
> 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.  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.
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> 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