Jetspeed buffers the content produced by portlets as Woonsan described.
Portlet Bridges often take a similar strategy, so my guess is that is where
the conflict is. When you say "It is based on Apache Portlet Bridge" - is
that a bridge housed here at Apache Portals? If yes, do you know the
version...


On Wed, Jul 17, 2013 at 7:06 AM, Woonsan Ko <[email protected]> wrote:

> Hi Ron,
>
> Jetspeed-2 captures the rendered content of a portlet window by using
> PortletRenderResponseContextImpl [1].
> The pluto's portlet render response implementation [2] is given the above
> context implementation by Jetspeed-2.
> The context (PortletRenderResponseContextImpl) has a portlet content
> object which stores the (cacheable) rendered content.
>
> Regarding "The portlet renders, then the theme renders below it ...",
> maybe the (custom) portlet bridge tries to unwrap its given portlet
> response object somehow and so it writes to the portal servlet response
> directly? If it just used portlet response to write content, then it would
> be okay.
>
> HTH and good luck,
>
> Woonsan
>
> [1]
> http://svn.apache.org/repos/asf/portals/jetspeed-2/portal/trunk/components/jetspeed-portal/src/main/java/org/apache/jetspeed/container/impl/PortletRenderResponseContextImpl.java
> [2] org.apache.pluto.container.impl.RenderResponseImpl
>
>
>
>
>
> >________________________________
> > From: Ron McNulty <[email protected]>
> >To: Jetspeed Users List <[email protected]>
> >Sent: Wednesday, July 17, 2013 4:05 AM
> >Subject: HTML capture from portlet apps - how does it work?
> >
> >
> >Hi all
> >
> >I have the unfortunate task of getting a portlet bridge application going
> under Jetspeed 2.2.2 (classic pipeline). It has run under IBM Portal 6 & 7
> for several years without problems. Now it needs a major upgrade, and I
> want to port it to Jetspeed so we can easily develop and unit test on our
> desktop machines.
> >
> >I have fixed most of the obvious stuff - IBM is often tolerant of errors
> that Jetspeed/Tomcat complain about.
> >
> >But I am left with one big problem. Basically, the app is recognised by
> Jetspeed, gets deployed and started (no error messages). The application
> appears in the admin pages, and the one portlet in the app is visible in
> the portlet chooser. But the rendering is wrong. The portlet renders, then
> the theme renders below it with no portlet content. It appears that the
> page aggregator fails to capture the portlet app's HTML output. It is not a
> page or theme problem, as if I choose another portlet for the page, all is
> sweet.
> >
> >The problem is almost certainly with the app. It is based on Apache
> Portlet Bridge, with local modifications (don't ask!). Personally I think
> the bridge is a toxic piece of software. I've checked the portlet.xml and
> web.xml and all the configuration information looks correct. The problem
> appears to be deep-seated.
> >
> >I have downloaded the Jetspeed 2.2.2 source, and started debugging. But I
> can't quite understand how the HTML output from a portal app is
> captured.Can someone explain how the HTML capture works? I thought is was
> via a valve or servlet filter, but that does not seem to be right. I'm not
> sure if the Jetspeed code or the underlying Pluto code handles this.
> Hopefully Woosan or David are listening to this group and can give me some
> pointers.
> >
> >Regards
> >
> >Ron McNulty
> >
> >
>



-- 
David

Reply via email to