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
