You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Scott T Weaver (JIRA)" <je...@portals.apache.org> on 2005/04/29 16:14:07 UTC
[jira] Resolved: (JS2-252) Fragments retain their previous content in certain cases
[ 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
Re: [jira] Resolved: (JS2-252) Fragments retain their previous content
in certain cases
Posted by Randy Watler <wa...@wispertel.net>.
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
RE: [jira] Resolved: (JS2-252) Fragments retain their previous content in certain cases
Posted by Scott T Weaver <sc...@binary-designs.net>.
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
Re: [jira] Resolved: (JS2-252) Fragments retain their previous content
in certain cases
Posted by Ate Douma <at...@douma.nu>.
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(CastorXmlPageManager.java:1632)
at org.apache.jetspeed.page.impl.CastorXmlPageManager.updatePage(CastorXmlPageManager.java:1658)
at org.apache.jetspeed.portlets.layout.MultiColumnPortlet.buildColumns(MultiColumnPortlet.java:240)
at org.apache.jetspeed.portlets.layout.MultiColumnPortlet.doView(MultiColumnPortlet.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(JetspeedPortletInstance.java:96)
at org.apache.jetspeed.container.invoker.LocalPortletInvoker.invoke(LocalPortletInvoker.java:190)
at org.apache.jetspeed.container.invoker.LocalPortletInvoker.render(LocalPortletInvoker.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
RE: [jira] Resolved: (JS2-252) Fragments retain their previous
content in certain cases
Posted by Santiago Gala <sg...@hisitech.com>.
El mar, 03-05-2005 a las 13:19 -0400, Scott T Weaver escribió:
> > Did you ever find a way to get on IRC? ;)
>
> Actually, if we can get this setup on a server,
> http://cgiirc.sourceforge.net/, I could use it.
>
> -Scott
>
We can also use IM for meetings. At least jabber and MSN do have ability
to do group chats. My jabber server is the one waiting for repair (it
was toasted by a spike from Iberdrola, my power provider). I'll move it
to another server if/when I finish my move at the server and connection
level.
The setup of IM in closed locations depends generally on having either
SOCKS (and then you're done, as it is fairly flexible), or the ability
to do relatively long time HTTP CONNECT to ports different than the
standard 443, which is not always available. For instance in the Univ.
where I work now CONNECT is completely closed, even for the standard
port, so I have to hack my way out of there, and they still block 6667
(standard IRC port) at the global level. I'm trying to check if some
server in freenode.net uses different ports to see if they have them
open. I highly doubt the server at codehaus has it, as it is not
integrated in any global IRC network.
Funny enough, as with most closed places, they base their security in
the "Chinese Wall" policy: isolating their users from the outside. This
has strong implications WRT productivity: for instance I can't use
version control in my teaching, except with a SVN/CVS server in my
laptop.
Even worse, they don't even notice that anybody with a sniffer can look
at and even impersonate all their internal traffic (they probably don't
even know the meaning of VPN). So they solve the wrong problem with the
wrong solution. i.e. Business as usual. :-)
> > -----Original Message-----
> > From: David Sean Taylor [mailto:david@bluesunrise.com]
> > Sent: Tuesday, May 03, 2005 10:53 AM
> > To: Jetspeed Developers List
> > Subject: Re: [jira] Resolved: (JS2-252) Fragments retain their previous
> > content in certain cases
> >
> > Raphaël Luta wrote:
> > > David Sean Taylor wrote:
> > >
> > >>
> > >> 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
> > >>
> > >
> > > Can you keep me in the loop on this review ? I can probably help you
> > > figure out the overall archietcture and I'd quite like to help finally
> > > make the asynchronous rendering process work properly.
> > >
> > Yes, of course.
> > We'll send an email out with a summary or you are welcome to join us
> > when we find a common time to meet
> >
> >
> > Scott T Weaver wrote:
> > > 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.
> >
> > Did you ever find a way to get on IRC? ;)
> >
> >
> >
> > --
> > 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
--
Santiago Gala <sg...@hisitech.com>
High Sierra Technology, SLU
RE: [jira] Resolved: (JS2-252) Fragments retain their previous content in certain cases
Posted by Scott T Weaver <sc...@binary-designs.net>.
> Did you ever find a way to get on IRC? ;)
Actually, if we can get this setup on a server,
http://cgiirc.sourceforge.net/, I could use it.
-Scott
> -----Original Message-----
> From: David Sean Taylor [mailto:david@bluesunrise.com]
> Sent: Tuesday, May 03, 2005 10:53 AM
> To: Jetspeed Developers List
> Subject: Re: [jira] Resolved: (JS2-252) Fragments retain their previous
> content in certain cases
>
> Raphaël Luta wrote:
> > David Sean Taylor wrote:
> >
> >>
> >> 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
> >>
> >
> > Can you keep me in the loop on this review ? I can probably help you
> > figure out the overall archietcture and I'd quite like to help finally
> > make the asynchronous rendering process work properly.
> >
> Yes, of course.
> We'll send an email out with a summary or you are welcome to join us
> when we find a common time to meet
>
>
> Scott T Weaver wrote:
> > 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.
>
> Did you ever find a way to get on IRC? ;)
>
>
>
> --
> 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
Re: [jira] Resolved: (JS2-252) Fragments retain their previous content
in certain cases
Posted by David Sean Taylor <da...@bluesunrise.com>.
Raphaël Luta wrote:
> David Sean Taylor wrote:
>
>>
>> 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
>>
>
> Can you keep me in the loop on this review ? I can probably help you
> figure out the overall archietcture and I'd quite like to help finally
> make the asynchronous rendering process work properly.
>
Yes, of course.
We'll send an email out with a summary or you are welcome to join us
when we find a common time to meet
Scott T Weaver wrote:
> 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.
Did you ever find a way to get on IRC? ;)
--
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
Re: [jira] Resolved: (JS2-252) Fragments retain their previous content
in certain cases
Posted by Raphaël Luta <ra...@apache.org>.
David Sean Taylor wrote:
>
> 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
>
Can you keep me in the loop on this review ? I can probably help you
figure out the overall archietcture and I'd quite like to help finally
make the asynchronous rendering process work properly.
--
Raphaël Luta - raphael@apache.org
Apache Portals - Enterprise Portal in Java
http://portals.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
RE: [jira] Resolved: (JS2-252) Fragments retain their previous content in certain cases
Posted by Scott T Weaver <sc...@binary-designs.net>.
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
Re: [jira] Resolved: (JS2-252) Fragments retain their previous content
in certain cases
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
RE: [jira] Resolved: (JS2-252) Fragments retain their previous content in certain cases
Posted by Scott T Weaver <sc...@binary-designs.net>.
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
Re: [jira] Resolved: (JS2-252) Fragments retain their previous content
in certain cases
Posted by David Sean Taylor <da...@bluesunrise.com>.
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 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);
--
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