02 Converting personDirectory.xml

Owned by Eric Dalquist
Last updated: May 06, 2008 by Mark MarkVersion comment
2 min read

uPortal 3.0 switched from a bundled Person Directory service API to the stand-alone Person Directory project. The primary change is a renaming of the packages but the configuration properties of some classes changed as well. Below are itemized instructions for converting a personDirectory.xml file from uPortal 2 to work in uPortal 3.

Move the File

In uPortal 2, the file was named personDirectory.xml and located in /uPortal/properties. In uPortal 3, the file is named personDirectoryContext.xml and located in /uPortal/portal-impl/src/main/resources/properties/contexts.

Rename the Package

Replace all instances of org.jasig.portal.services.persondir in the file with org.jasig.services.persondir.

CachingPersonAttributeDaoImpl

The CachingPersonAttributeDaoImpl in uPortal 2 automatically discovered the cache to use. With the stand-alone project the cache needs to be provided.

If you have a CachingPersonAttributeDaoImpl add the property:

<property name="userInfoCache">
    <bean class="org.jasig.portal.utils.cache.MapCacheFactoryBean">
        <property name="cacheFactory" ref="cacheFactory" />
        <property name="cacheName" value="org.jasig.services.persondir.USER_INFO" />
    </bean>
</property>

JdbcPersonAttributeDaoImpl

JdbcPersonAttributeDaoImpl was renamed to SingleRowJdbcPersonAttributeDao and moved into the org.jasig.services.persondir.support.jdbc package. Update the bean class attribute to org.jasig.services.persondir.support.jdbc.SingleRowJdbcPersonAttributeDao

DataSource Access

In the uPortal 2 file, access to the Portal DataSource was done via Spring's MethodInvokingFactoryBean. Although the API is still available, this will not work in uPortal 3 and will cause the portal to fail to start. The portal's DataSource is now available as a Spring bean named PortalDB which should be injected instead.

For example the following xml snippet from the uPortal 2 file:

<constructor-arg index="0">
    <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
        <property name="staticMethod">
            <value>org.jasig.portal.RDBMServices.getDataSource</value>
        </property>
    </bean>
</constructor-arg>

Should be replaced with the following in the uPortal 3 file:

<constructor-arg index="0" ref="PortalDb" />

LdapPersonAttributeDaoImpl

LdapPersonAttributeDaoImpl was renamed to LdapPersonAttributeDao and moved into the org.jasig.services.persondir.support.ldap package. Update the bean class attribute to org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao

The ldapServer property which expected an ILdapServer has been replaced with the contextSource attribute which expects a ContextSource See the next section on getting access to the portal's ContextSource

LDAP Server Access

In the uPortal 2 file, access to the Portal LDAP server was done via Spring's MethodInvokingFactoryBean. uPortal 3 and Person Directory are now using the Spring-LDAP framework to manage LDAP access. The portal's LDAP servers are now configured in the ldapContext.xml file and the appropriately named ContextSource from that file should be used instead.

For example the following xml snippet from the uPortal 2 file:

<property name="ldapServer">
	<bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
		<property name="staticMethod">
			<value>org.jasig.portal.ldap.LdapServices.getDefaultLdapServer</value>
		</property>
	</bean>
</property>

Should be replaced with the following in the uPortal 3 file:

<property name="contextSource" ref="defaultLdapContext" />

This supposes that there is a ContextSource named defaultLdapContext configured in the ldapContext.xml file.