Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
2.0-M2
-
None
Description
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.