CustomizerVelocityPortlet broken

[Glenn Golden <gg...@umich.edu>]

I'm fixing the bug that a CustomizerVelocityPortlet's custom customizer is
no longer being called when the user customizes the portlet; instead the
standard portlet customizer is used.

I've tracked this down to the JetspeedTool's getCustomizer() call.  It's
passed a "Portlet" which is a VelocityPortletControl, and digs in with
p.getPortlet() to get the portlet within.  The portlet is a
CacheableStatefulPortletWrapper.

"If (p instanceof PortletCustomizer)" - well this thing is NOT an instance
of PortletCustomizer.

Looking inside this CacheableStatefulPortletWrapper, I see a wrappedPortlet,
which is a CustomizerVelocityPortlet...

Is this CacheableStatefulPortletWrapper thing new?  It looks like we need to
be able to "dig in" to this, as well as into the control, to find the real
portlet hiding inside.

I'll keep looking, but if bells are ringing in anyone's heads so far, please
post info for me!

Thanks.

- Glenn
 
--------------------------------------------
Glenn R. Golden, Systems Research Programmer
University of Michigan School of Information
ggolden@umich.edu               734-615-1419
http://www-personal.si.umich.edu/~ggolden/
--------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: CustomizerVelocityPortlet broken

[David Sean Taylor <da...@bluesunrise.com>]

Ah, my suspicions were correct.
The portlet customizer was working fine up until about the same time
that the wrapper stuff was committed.

> Is this CacheableStatefulPortletWrapper thing new?  It looks 
> like we need to be able to "dig in" to this, as well as into 
> the control, to find the real portlet hiding inside.

Its new. It should always delegate to its wrapped portlet. Its an
interceptor, meant to put 'declarative' security constraints into
portlet access.

Sounds like youre on to it -- keep digging! ;)

> -----Original Message-----
> From: Glenn Golden [mailto:ggolden@umich.edu] 
> Sent: Thursday, March 28, 2002 1:15 PM
> To: Jetspeed-Dev (jetspeed-dev@jakarta.apache.org)
> Subject: CustomizerVelocityPortlet broken
> 
> 
> I'm fixing the bug that a CustomizerVelocityPortlet's custom 
> customizer is no longer being called when the user customizes 
> the portlet; instead the standard portlet customizer is used.
> 
> I've tracked this down to the JetspeedTool's getCustomizer() 
> call.  It's passed a "Portlet" which is a 
> VelocityPortletControl, and digs in with
> p.getPortlet() to get the portlet within.  The portlet is a 
> CacheableStatefulPortletWrapper.
> 
> "If (p instanceof PortletCustomizer)" - well this thing is 
> NOT an instance of PortletCustomizer.
> 
> Looking inside this CacheableStatefulPortletWrapper, I see a 
> wrappedPortlet, which is a CustomizerVelocityPortlet...
> 
> Is this CacheableStatefulPortletWrapper thing new?  It looks 
> like we need to be able to "dig in" to this, as well as into 
> the control, to find the real portlet hiding inside.
> 
> I'll keep looking, but if bells are ringing in anyone's heads 
> so far, please post info for me!
> 
> Thanks.
> 
> - Glenn
>  
> --------------------------------------------
> Glenn R. Golden, Systems Research Programmer
> University of Michigan School of Information
> ggolden@umich.edu               734-615-1419
> http://www-personal.si.umich.edu/~ggolden/
> --------------------------------------------
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
> For 
> additional commands, 
> e-mail: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>