Sakai, ditch the custom classloaders

A few years ago I added support to the Sakai Maven Plugin to deploy everything that normally goes into /shared/lib and common/lib into just /lib, as per the standard Tomcat classloader layout.

To use, add to the build command. Everything gets deployed to /lib and Sakai starts up without any modifications (except the standard connector modification in server.xml and the optional performance improvements in

Enjoy the future!

Sakai 11: Java 8, Tomcat 8

Sakai 11 now requires Java 8 and Tomcat 8.

However, when you upgrade (and configure), you’ll notice a rather long startup time due to a change in the JAR scanning behaviour of Tomcat:

Server startup in 252800 ms

This scanning is unnecessary for Sakai though, so add this to your Tomcat/conf/context.xml file:


    <JarScanFilter defaultPluggabilityScan="false" />

And now you should have a much happier (and usable) startup time:

Server startup in 55836 ms

Got any more tips to improve startup times? Post in the comments!

Reduce your Sakai CLE startup time

There is a current discussion on the sakai-dev list about the recent switch to Tomcat 7 and some new features in Tomcat that meant startup times took a bit longer than they used to.

As it turns out there is a new feature in Tomcat 7 that scans jar files for various Servlet 3 features. However the CLE code doesn’t use any Servlet 3 features yet.

So we can just disable the scanning and cut our startup times by a fair amount.  On my local full trunk deployment I was able to reduce my startup from 175 seconds down to 89 seconds.

To do this, in, set:


So far, all CLE tools in 2.10 appear fully functional. If you try this and experience issues, please let me know in the comments, or post on list.