portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Watler <wat...@wispertel.net>
Subject Re: [jira] Resolved: (JS2-252) Fragments retain their previous content in certain cases
Date Wed, 18 May 2005 14:12:33 GMT
Scott/Ate:

FYI, this method will be deprecated with the PortalSite component... so 
dont put too much into fixing it if you can avoid it.

Randy

Scott T Weaver wrote:

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



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