uPortal3 Adoption - Johns Hopkins
Work In Progress
This page is not nearly ready for public consumption. But it is what it is, and if there is interest I am more than willing to expand on any of this information.
--Chris
Microsoft SQL Server
A Warning About uPortal 3 and MS SQL Server
http://www.unicon.net/node/1076
uPortal 3 Manual - MSSQL with the jTDS JDBC Driver http://www.ja-sig.org/wiki/display/UPM30/05+MSSQL+with+the+jTDS+JDBC+Driver
Performance Tuning
It was absolutely critical that we applied all of the performance patches beneath UP-2124. See the following e-mail threads for further information as well:
- http://www.nabble.com/uP3-Performance-Issue-td19402711.html
- http://www.nabble.com/Re%3AuP3-Performance-Issue-td19436803.html
esup-portal-ws Project
We used the esup-portal-ws project in our uPortal 2.6.1+ instance here at Johns Hopkins, so this was obviously a necessary component to include in our recent upgrade to uPortal 3. During the process I was able to fully mavenize the esup-portal-ws project from the most recent checkout (Revision 26, at the time) from the subversion.cru.fr SVN trunk (see attached). I also ended up having to apply a patch to the axistools-maven-plugin mojo
in order it to build properly, which is attached to this page as well. (See the MAXISTOOLS-6 issue on the Maven 2.x Axis Tools Plugin JIRA for further information regarding this patch...)
Person Attributes PreInterceptor for the UW-Madison Web Proxy Portlet
We at Johns Hopkins need a nice mechanism to provide Person Attributes via the Web Proxy Portlet similar to how CWebProxy currently does using the cw_person
and/or the upc_localConnContext
configuration parameters. I was able to accomplish this goal by developing a custom "Pre-Interceptor" class which makes a call out to the esup-portal web services for the attribute consumption. See the attached Java file, which is Spring-loaded in kind of a funky way that is apparently consistent with the style used in this portlet. You'll also have to add the following Bean definition to your applicationContext.xml
, which resides in WEB-INF (and not on the classpath):
<bean id="portalService" class="org.esupportail.portal.ws.client.support.uportal.BasicUportalServiceImpl"> <property name="url" value="http://localhost:8080/uPortal/services/UportalService"> <description> The URL that responds to the portal web service. </description> </property> </bean>
I also had to add axis and esup-portal-ws (needs a home!) dependencies to the pom.xml
of the Web Proxy Portlet project:
<dependency> <groupId>org.esupportail.portal.ws</groupId> <artifactId>esup-portal-ws-client</artifactId> <version>1.1.0-SNAPSHOT</version> <scope>compile</scope> </dependency> <dependency> <groupId>axis</groupId> <artifactId>axis</artifactId> <version>1.4</version> <scope>runtime</scope> </dependency>
At any rate, it works like a champ. As a next step I'd like to make this interceptor configurable, to allow the selection of specific attributes rather than all of them, then possibly contributing it back to the actual Web Proxy Portlet project. Or we could completely scrap this effort in favor of something a little more modern.
Updated HTTP Person Attribute DAOs for use with person-directory (see PERSONDIR-37)
This functionality was necessary for handling our multiple entry points...NEED TO FLESH THIS SECTION OUT FURTHER...
You will obviously need to configure the DAOs in the personDirectoryContext.xml
file in uportal-impl
in order to use the HTTP Person Attribute DAOs, for example:
<bean id="mergedPersonAttributeDao" class="org.jasig.services.persondir.support.MergingPersonAttributeDaoImpl"> <property name="personAttributeDaos"> <list> <bean class="org.jasig.services.persondir.support.EchoPersonAttributeDaoImpl"/> . . . <ref bean="httpCookieAttributeSource"/> </list> </property> </bean> . . . <bean id="httpCookieAttributeSource" class="edu.jhu.services.persondir.support.http.HttpCookiePersonAttributeDao"> <constructor-arg> <value>cachePrefix</value> </constructor-arg> <property name="columnsToAttributes"> <map> <entry key="cookieName"><value>cookieName</value></entry> </map> </property> </bean>
In addition, you will also need to configure the following cache in the cacheContext.xml
:
<!-- | Service used by person-directory to cache HTTP DAO Person Attributes. +--> <bean id="httpPersonAttributeCachingService" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"> <property name="targetClass" value="edu.jhu.services.persondir.support.http.HttpPersonAttributeCachingService" /> <property name="targetMethod" value="getInstance" /> </bean> <bean class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"> <property name="targetObject" ref="httpPersonAttributeCachingService" /> <property name="targetMethod" value="setCacheFactory" /> <property name="arguments"> <list> <ref bean="cacheFactory"/> </list> </property> </bean>
And add a cache entry into the ehcache.xml
configuration:
<cache name="edu.jhu.services.persondir.support.http.CACHE" eternal="false" maxElementsInMemory="150" overflowToDisk="false" diskPersistent="false" timeToIdleSeconds="0" timeToLiveSeconds="600" memoryStoreEvictionPolicy="LRU" />
Lastly, add the appropriate filter to uPortal's web.xml. For the cookie DAO add the cookie filter and for the HTTP header DAO add the HTTP header filter.
<filter> <filter-name>HttpCookieFilter</filter-name> <filter-class>edu.jhu.services.persondir.support.http.HttpCookieFilter</filter-class> </filter> <filter-mapping> <filter-name>HttpCookieFilter</filter-name> <servlet-name>Login</servlet-name> </filter-mapping>