Argh, near panic when a new clustered installation of Lotus Connections 2.5.0.1 starts #failing

Having spent 2-3 days this week, preparing for, and building a clustered installation of Lotus Connections 2.5.01, I was feeling a little panic-stricken yesterday, when I was unable to log into Connections, either directly into Profiles, or into any other service, all of which use Profiles.

I was getting exceptions such as: -

19/05/10 17:20:23:625 BST] 0000002c WebApp        E   Exception caught while initializing context 
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'com.ibm.lconn.core.appext.api.SNAXPersonService' defined in URL [wsjar:file:/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/connut-1Node01Cell/Profiles.ear/peoplepages.war/WEB-INF/lib/lc.appext.core.impl-2.5.jar!/META-INF/spring/lconn-service-context.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [com.ibm.lconn.core.appext.impl.SNAXPersonServiceImpl]: Constructor threw exception; nested exception is java.lang.ExceptionInInitializerError        at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:243)

in the SystemOut.log for Profiles, which gave me great cause for concern.

Reading through this forum thread: -

  Upgraded to 2.5, now Websphere doesn't completely start

gave me a few pointers, but nothing really concrete.

When I dug a little further into the logs, I found this: -

Caused by: com.ibm.connections.directory.services.exception.DSRuntimeException: com.ibm.connections.directory.services.exception.DSException: CLFRK0004E: SSO domain name '.foobar.snafu.com' is not configured properly for host name 'http://<HOSTNAME.DOMAIN.COM>:9085/communities/dsx/'!

( I've anonymised the domain names etc. )

This started me thinking and I checked the /etc/hosts file of the Linux box on which Connections is running.

Sure enough, the .foobar.snafu.com domain matched a "private" network that only exists between Connections and the back-end data server on which NFS is being used for shared file systems etc.

I'm guessing that WAS was looking at, perhaps, the first IP address on the system, doing a reverse lookup via /etc/hosts and then returning the domain name portion of its hostname.

The solution ?

Set the SSO domain name to something sensible ( matching the domain name portion of the network on which ALL the Connections and Portal and Quickr servers are sitting ).

I did this via the Integrated Solutions Console (ISC), via Security -> Secure administration, applications and infrastructure -> Web security -> single sign-on (SSO), setting the Domain name field.

Once I restarted the Connections cluster, all was well, and I was able to log into Profiles, and access all the other services.

Nice