Re: HTML capture from portlet apps - how does it work [Solved]

[Ron McNulty <rm...@clear.net.nz>]

Hi David & Woosan

Turned out that our app servlet (which extends GenericServlet) was writing 
to the servletResponse inside the portletResponse passed by Jetspeed to the 
portlet app. I tried using the containerResponse, but that too caused 
immediate rendering. I put a simple wrapper around the servletResponse, 
using the PrintWriter passed in the portletResponse, and all came right.

Thanks again for your help.

Regards

Ron

----- Original Message ----- 
From: "Ron McNulty" <rm...@clear.net.nz>
To: "Jetspeed Users List" <je...@portals.apache.org>
Sent: Friday, July 19, 2013 9:42 AM
Subject: Re: HTML capture from portlet apps - how does it work?


Hi David & Woosan

Thanks for your prompt replies - the support here is better than any 
commercial support I have ever used.

I'm not sure of the portlet bridge version, or the level of customisation - 
it is about 6 years old and we have shifted from CVS to SVN since then, and 
the CVS history is hard to access.

I think you are right about the wrong response being used. What I am seeing 
is:
  a.. Two instances of PortletRenderResponseContextImpl get created - one 
for the portlet and one for the page
  b.. The portlet renders, but the output goes direct out to the browser. 
PortletRenderResponseContextImpl.getPrintWriter() is not called.
  c..  The page renders to the PortletRenderResponseContextImpl instance. 
getPrintWriter() is called
  d.. The page (theme with no portlet content) is rendered to the browser.
I think the configuration is correct, as debugging a "good" page mimics the 
above sequence, but getPrintWriter() does get called in step 2.

I'm off out of town until Monday, so I won't be doing any more digging until 
then.

Thanks again for your input.

Regards

Ron


From: "David Taylor" <da...@gmail.com>
To: "Jetspeed Users List" <je...@portals.apache.org>; "Woonsan Ko" 
<wo...@yahoo.com>
Sent: Thursday, July 18, 2013 5:55 AM
Subject: Re: HTML capture from portlet apps - how does it work?


> 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 <wo...@yahoo.com> 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 <rm...@clear.net.nz>
>> >To: Jetspeed Users List <je...@portals.apache.org>
>> >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
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-user-help@portals.apache.org