Re: UserInfoService question

[Eric Dalquist]

The UserInfoService is in 1.1.1 (which uP3 is now running on BTW, thanks all!) but there is some logic related to the USER_INFO Map that is in the RenderRequestImpl, because of how some of our domain object model work I need my own logic for USER_INFO handling and would rather Pluto completely delegate to this service instead of just partially delegate. Right now Pluto expects the UserInfoService to return all attributes for a user, the problem is in uP3 the list of user attributes is affected by the portlet the attributes are for.

-Eric

Charles Severance wrote:

Eric - I think that this is there already (in 1.1.1). I attach our optional container services - note that the 1.1.1. stuff is commented out so my trunk works with 1.1.0.

/Chuck

On Mar 5, 2007, at 12:40 PM, Eric Dalquist wrote:

Actually, to expand on this. The default logic in PortletRequest.createUserInfoMap() doesn't mesh well with what uPortal needs to do. I can override the method but because of the class hierarchy I have to override it twice, once in a custom RenderRequest impl and once in a custom ActionRequest impl. Would it be possible to move all of this logic into an the optional UserInfoService? That would let me override it in one location for the container.

-Eric

Eric Dalquist wrote:

Any reason why UserInfoService doesn't pass the PortletWindow in along with the request? I realize I can pass it as a request attribute or some such but it would seem to be a bit easier if it could be provided.

-Eric

smime.p7s
Description: S/MIME Cryptographic Signature