You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by Stefan Hepper <st...@hursley.ibm.com> on 2004/02/02 16:42:26 UTC

Re: Portlet invocation question

Hi Rickard,
thanks for the feedback.

The reason for using the servlet container for invoking portlets is to 
reuse the existing servlet container infrastructure for deployment, 
classloading and life cycle management. In our experience calling the 
request dispatcher is not a big overhead compared to the total time to 
create the page.

Stefan


Rickard Öberg wrote:

> Hi!
> 
> I'm considering integrating Pluto as the portlet container for our 
> CMS/portal product. One thing that I looked at first was the performance 
> overhead of each invocation, and one part in particular seems 
> problematic: each portlet invocation is done by delegating to a servlet 
> (PortletServlet) through a RequestDispatcher.
> 
> Since there is some overhead with calling servlets, and I couldn't find 
> any direct reason in code as to why this delegation takes place, I would 
> be interested to know the design decision behind this. Why isn't the 
> PortletInvoker calling the portlet directly?
> 
> The only reason I can think of is that the PortletServlet should hold 
> the portlet in order to ensure that the correct class is being used 
> (i.e. to play nice with redeployment of portlet apps). Is this the main 
> reason? Or are there others.
> 
> Other than that most of the code looks ok, with a healthy overdose of 
> factories all around :-)
> 
> To explain my scenario a bit more, since this is for a product that is 
> primarily a CMS and not a portal, we typically have ~15-20 portlets on 
> each page, where a portlet can be as simple as just a piece of formatted 
> text, or a single image. Or it can be more complex, as a discussion 
> forum. But, because of the potentially massive number of finegrained 
> portlets it is critical that the overhead is minimal
> 
> I guess this also puts my vote on the issue of "minimalistic vs 
> performant" discussion: I *definitely* want Pluto to be performant and 
> production ready, and it seems most other people working on Pluto wants 
> to use it not only as an RI.
> 
> /Rickard
> 
>