I just submitted a patch for this JIRA: http://www.ja-sig.org/issues/browse/UP-933
That should solve the issue. It just exposes a request attribute called org.jasig.portlet.USER_INFO_MULTI to Portlets. This attribute always returns a Map<String, List> that comes from IPersonAttribute.getAttributeValues(). -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Chris Doyle Sent: Tuesday, November 17, 2009 2:43 PM To: [email protected] Subject: [uportal-dev] Multi-valued Attributes in PersonDirectoryUserInfoService I have developed a proposed patch for handling multi-valued person attributes in uPortal's PersonDirectoryUserInfoService implementation of Pluto's UserInfoService Interface. I have recently been examining the values returned in the PortletRequest.USER_INFO attribute from within in a portlet deployed to our development uPortal 3.1.1 instance. These values are ultimately populated by a call to the getUserInfo() method of a Spring-configured UserInfoService implementation as defined in portletContainerContext.xml. (NOTE: the returned Map is NOT explicitly parameterized in the Interface definition.) There are several implementations provided by uPortal beneath the org.jasig.portal.portlet.container.services package: CachedPasswordUserInfoService.java CasTicketUserInfoService.java MergingUserInfoService.java PersonDirectoryUserInfoService.java In our case, and by default, uPortal is configured to use the MergingUserInfoService, which aggregates one or more UserInfoService implementations. We are specifically interested in accessing person attributes, which are provided by the configured PersonDirectoryUserInfoService, and ultimately return values populated by Person Directory. Herein lies our concern: the current PersonDirectoryUserInfoService does NOT return all values for multi-valued attributes, rather it returns the FIRST value ONLY. I'm assuming this was intended by design, but we have a specific need to access all values of a particular attribute in our configuration. Currently, the returned map of the getUserInfo() method is an explicitly parameterized Map<String, String>. I am proposing that we modify this to either: Option 1: Map<String, Object> where multi-valued attributes return a List<String> value and single-valued attributes return a String value Option 2: Map<String, List<String>> I have coded and tested my patch both ways, and I definitely prefer Option 1. Many portlets have been coded to treat the returned value as a String, which obviously explodes with a ClassCastException if Option 2 is employed. However, I suppose the argument could be made against Option 1 that returning either a String OR a List value in the Map is inconsistent. While I agree with this, I also tend to think that if one is going to access the value of a specific attribute that falls under this exception, that they would operate under the explicit knowledge of this already and handle it accordingly. Honestly, I'd imagine that at least 90% of the person attributes in any given portal configuration are single-valued anyway, so it wouldn't matter much. Furthermore, I'm not sure how many other folks are actually using the information from the PortletRequest.USER_INFO attribute in their Portlet development, though I would definitely be interested in hearing back from anyone who is. Either way, modifications would need to be made in several places of each of the aforementioned UserInfoService implementations in uPortal to accommodate our specific needs. Or perhaps there is an Option 3 that I have not considered? I am definitely very interested in hearing any feedback on the subject. Is this a reasonable approach for a valid concern? Or is there good reason to leave this alone entirely? Many thanks in advance, --Chris -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
