Asked and answered: Why does Jetspeed re-use an instance of my Portlet when multiple occurrences are deployed in the portal?

[David Roytenberg <dr...@freebalance.com>]

To the readers of the Jetspeed developers' list:

The short answer is that my portlet inherited from AbstractPortlet
rather than AbstractInstancePortlet.  See below for details.

Regards,

David Roytenberg

-----Original Message-----
From: David Roytenberg 
Sent: Monday, August 15, 2005 11:37 AM
To: 'David Sean Taylor'
Subject: FW: Customization with latest builds

Hi David,

     I found the root of the problem and the reason the change describe
above fixed it.  The GenericMVCPortlet extends AbstractInstancePortlet
which over-rides the getHandle method and distinguishes the portlet
instances by their IDs.  This is precisely the behavior that was missing
in the inheritance form AbstractPortlet.  Thankyou for your time and
interest.
 
     Best regards,

          David

-----Original Message-----
From: David Roytenberg 
Sent: Monday, August 15, 2005 10:37 AM
To: 'David Sean Taylor'
Subject: RE: Customization with latest builds

Hi David,

   Thanks for your reply.  We are using Jetspeed 1.5.  Our portlet
extends the AbstractPortlet.  It is an "instance" portlet.  I have
stepped through the code while rendering and I now understand the
behavior that is causing our problem.  

   When the portal is rendered, the Jetspeed tool builds a tree
structure of all of the portlets in the portal.  This structure is then
referenced when the portal is rendered.  For each portlet in the portal,
the PSML is read and a portlet instance is created, (wrapped in a
CacheableStatefulPortlet object).  

What I noticed about our portlet that is causing the problem is that
rather than creating a new instance of the portlet for each occurrence,
the portlet instance is being reused under certain circumstances.  In
particular, where portlet instances differ only in their EIDs, the same
instance is referenced by each BasePortletSet control.  Since each of
these objects sets the EID from the PSML when they are initialized, all
of the controllers end up referencing the last portlet instance loaded
from the PSML.  The controls displayed to the user, link to URLs which
specify the EID of the last instance of the portlet in the portal, no
matter which instance is actually selected.  When the user tries to
customize one of the other instances the changes are applied to the last
one.

    Once the customization changes are applied, the last one no longer
looks like the others in the PSML, and all of the uncustomized instances
end up referencing the next-to-last occurrence.  However if two
instances are customized with the same parameters the problem recurs
separately for them and both instances will reference the last one.  I
actually made this problem go away by switching from extending
AbstractPortlet and instead extending GenericMVCPortlet, but since the
docs discourage this, I wonder if there is instead a way to configure
our portlet so that the unwanted caching behavior does not occur?

    I will be happy to post this to the mailing list.  What's the eMail
address of the list?

    Regards,

         David

-----Original Message-----
From: David Sean Taylor [mailto:david@bluesunrise.com] 
Sent: Friday, August 12, 2005 1:57 PM
To: David Roytenberg
Subject: Re: Customization with latest builds

David Roytenberg wrote:
> Hi David,
> 
>  
> 
>     I read your response to a customization question in the Jetspeed 
> Archive and thought you might be able to help me with the following 
> question.

Best to send questions to the jetspeed-user list so everyone can 
benefit/help

Lets start at the beginning: what version of Jetspeed are you using?

The 1.x customizer is not so stable...

-- 
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