portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: CustomizerVelocityPortlet broken
Date Tue, 02 Apr 2002 21:14:42 GMT
David Sean Taylor wrote:

>IMO - the wrapper isn't correctly implemented.
>Java now has java.lang.reflect.Proxy to proxy interfaces.
>>>From the javadocs:
>
><quote>
>A proxy instance has the following properties: 
>
>Given a proxy instance proxy and one of the interfaces implemented by
>its proxy class Foo, the following expression will return true: 
>     proxy instanceof Foo
> and the following cast operation will succeed (rather than throwing a
>ClassCastException): 
>     (Foo) proxy
></quote>
>
>I haven't had a chance to review the wrapper code, Im deep in some
>database shiite right now and won't have time for a few days.
>
>
>Could you please figure out exactly what it does, and then either:
>
>- rewrite it 
>- get rid of it
>
>The approach you are taking, to search for all places where we use
>'instanceof' will patch the problem now, that is until some one comes
>along and codes 'instanceof' again...
>

The wrapper is an interceptor for security calls.

I noticed a few of the marker interfaces (Cacheable, Stateful) but I 
missed this one. Sorry about this. I did not notice this marker. Also, 
notice that there is a combinatorial explosion of classes if we keep on 
using these interfaces (we already have four classes for 3 interfaces, 
and it will grow wildly).

If we are ready to require jdk1.3 for Jetspeed (I'm not sure at all 
about this) we could use the java.lang.reflect.Proxy class.

This is the reason I did not use it.

I agree that when we move to jdk1.3, the java.lang.reflect.Proxy class 
is a good alternative to these classes.

>
>>-----Original Message-----
>>From: Glenn Golden [mailto:ggolden@umich.edu] 
>>Sent: Thursday, March 28, 2002 4:37 PM
>>To: 'Jetspeed Developers List'
>>Subject: RE: CustomizerVelocityPortlet broken
>>
>>
>>The problem is that there are two design patterns in use with 
>>these wrapped portlets - the wrapping, and marker interfaces 
>>(such as, in our case, PortletCustomizer).
>>
>>These appear to be in conflict - you can't see the marker 
>>interfaces that a class implements if it's wrapped.  The 
>>wrapper surfaces the wrapped class's API, but testing 
>>"instanceof" is not made explicit in the API, so it not 
>>surfaced by the wrapping.
>>
Sorry, I missed the PortletCustomizer interface.

>>
>>I'll replace our use of PortletCustomizer marker interface 
>>with some new method of the Portlet API, something like 
>>'public boolean isOwnCustomizer()" -I'm having trouble 
>>getting a good name.
>>
>>I'll search for other instanceof PortletCustomizer" code and 
>>fix them all.
>>
>>Do we use other marker interfaces that we should likewise fix?
>>
I missed this one, but I think I took care of the rest (Cacheable and 
Stateful).

>>
>>I'll have a patch tonight or tomorrow for this.
>>

Sorry for the mess.

>>
>>- 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/
>>--------------------------------------------
>>
>>
>>
>>>-----Original Message-----
>>>From: David Sean Taylor [mailto:david@bluesunrise.com]
>>>Sent: Thursday, March 28, 2002 5:17 PM
>>>To: 'Jetspeed Developers List'
>>>Subject: RE: CustomizerVelocityPortlet broken
>>>
>>>
>>>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: <mailto:jetspeed-dev-help@jakarta.apache.org>
>>>>
>>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:   
>>><mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
>>>For
>>>additional commands, 
>>>e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
>>>
>>--
>>To unsubscribe, e-mail:   
>><mailto:jetspeed-dev-> unsubscribe@jakarta.apache.org>
>>For 
>>additional commands, 
>>e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
>>
>>
>
>
>
>--
>To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>
>




--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message