Superpatterns

As a ‘Project Owner’ at OpenSSO, one of my more pleasurable duties is approving requests for project membership. Requests arrive daily; the ‘Observer’ role is granted without question – folks asking for ‘Developer’ roles are granted ‘Observer’ status pending their acceptance as contributors (there’s a little but of process). While the OpenSSO source code and binaries are freely available, OpenSSO Observers get to subscribe to the mailing lists, edit the wiki, report issues and more.

A little while ago I had to provide some project statistics for an analyst call, and realized that we were at around 380 members. Since then I’ve been watching the membership requests and waiting for the 400th member to arrive. Well – today’s the day – welcome, dmaio!

And, if you’re reading this and are not participating in OpenSSO yet, well, just click here to join.

As you might already know, OpenID.sun.com has been live for a few days now. I have my shiny new OpenID (http://openid.sun.com/metadaddy) and have already used it to log in to the Project Concordia wiki and add myself to the list of participants. Everything seems to be working as it should.

It’s a fitting time, then, to start explaining how we deployed OpenID, and Hubert has started doing exactly that with this blog entry on the architecture of OpenID.sun.com. As you can see from Hubert’s description, the OpenID deployment is based on OpenSSO and its OpenID extension, so any interested party can go grab the source and try it out for themselves. In fact, some already have.

I’ve been meaning to blog about this for a while, but haven’t been able to scrape together a few minutes. Anyway, if you’ve been reading Superpatterns for a while you’ll know that I use Tomcat on Ubuntu to run OpenSSO. I wrote a little while ago about some problems with Tomcat in Ubuntu 7.04 ‘Feisty Fawn’ – Ubuntu hanging at startup due to issues with catalina.out and security policy needing to be updated due to a change in where Tomcat keeps web applications on disk.

Another issue I’ve seen is the following stack trace when parsing XML:

javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found
javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:119)
com.sun.identity.shared.xml.XMLUtils.print(XMLUtils.java:674)
com.sun.identity.saml.assertion.Assertion.parseAssertionElement(Assertion.java:191)
com.sun.identity.saml.assertion.Assertion.(Assertion.java:147)
com.sun.identity.wsfederation.profile.RequestSecurityTokenResponse.(RequestSecurityTokenResponse.java:131)
com.sun.identity.wsfederation.profile.RequestSecurityTokenResponse.parseXML(RequestSecurityTokenResponse.java:62)
com.sun.identity.wsfederation.servlet.RPSigninResponse.process(RPSigninResponse.java:93)
com.sun.identity.wsfederation.servlet.WSFederationServlet.doPost(WSFederationServlet.java:143)
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
[...]

A quick Google turns up this blog entry from Andrew Beacock in the UK. The issue is that, previously, Xalan was included in JDK 1.4, but since then, the Apache community has chosen XSLTC as the default processor for developing XSLT 2.0, and JDK 1.5 followed suit for JAXP 1.3. I’m running Tomcat on Sun’s 1.5.0_11-b03 JVM, hence the missing TransformerFactoryImpl. The bottom line is this: grab Xalan for yourself and put it in your web app’s WEB-INF/lib directory.

If you’re working with OpenSSO, you can just copy xalan.jar, xercesImpl.jar, xml-apis.jar and serializer.jar from Xalan to opensso/products/extlib, rebuild the OpenSSO WAR and you should be good to go.

And, again, before anyone asks “Why aren’t you using Glassfish?” – I am, I’m just using Tomcat as well, since a lot of the OpenSSO contributors use it. Their pain is my pain