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 Eric Dalquist <er...@doit.wisc.edu> on 2008/06/23 20:16:38 UTC
Refactor request attribute handling (PLUTO-489)
I created https://issues.apache.org/jira/browse/PLUTO-489 this morning
along with a patch that creates a new optional service for handling of
request attributes. PortletRequestImpl is modified to delegate all four
request attribute methods (get, names, set, remove) to this interface,
included in the move is the createUserInfoMap method from
PortletRequestImpl.
The motivation behind the change is to allow a portal to have influence
on the handling of request attributes and filtering of the USER_INFO Map
without having to re-implement the entire PortletRequest hierarchy.
The patch attached in Jira is functionally identical to the existing
code. Current users of Pluto that use their own direct implementations
of the OptionalContainerServices interface will have to implement a new
method from that interface when upgrading. To retain existing behavior
that implementation would simply be to return the provided
DefaultRequestAttributeService.
I'd like to propose this change for 1.1.6 and 2.0.0. I'm going to hold
off on any commits until I hear back on this list.
-Eric
Re: Refactor request attribute handling (PLUTO-489)
Posted by Eric Dalquist <er...@doit.wisc.edu>.
I just wanted to check if anyone had any comments on this before I went
ahead and committed the changes this week.
-Eric
Eric Dalquist wrote:
> I created https://issues.apache.org/jira/browse/PLUTO-489 this morning
> along with a patch that creates a new optional service for handling of
> request attributes. PortletRequestImpl is modified to delegate all
> four request attribute methods (get, names, set, remove) to this
> interface, included in the move is the createUserInfoMap method from
> PortletRequestImpl.
>
> The motivation behind the change is to allow a portal to have
> influence on the handling of request attributes and filtering of the
> USER_INFO Map without having to re-implement the entire PortletRequest
> hierarchy.
>
> The patch attached in Jira is functionally identical to the existing
> code. Current users of Pluto that use their own direct implementations
> of the OptionalContainerServices interface will have to implement a
> new method from that interface when upgrading. To retain existing
> behavior that implementation would simply be to return the provided
> DefaultRequestAttributeService.
>
> I'd like to propose this change for 1.1.6 and 2.0.0. I'm going to hold
> off on any commits until I hear back on this list.
>
> -Eric