[Building Sakai] need to delay startup of quartz

[Charles Hedrick]

We need to delay the startup of quartz until the end. Either that or carefully audit all the jobs.

We just had a system come up with Samigo non-operational. 

There are two static initializers calling IntegrationContextFactory getInstance(). In the log there’s an error from there, Unable to read integration context, null pointer. That implies that the following code failed:
        FactoryUtil.setUseLocator(true);
        instance = FactoryUtil.lookup();
If you look at FactoryUtil, it ends up asking Spring for the bean org.sakaiproject.tool.assessment.integration.context.spring.IntegrationContext. But that isn’t set until the war file is deployed. But Quartz starts as soon as the service layer is started, before the war files have been deployed. So if it calls this code, the code will fail, since it depends upon the war file. But since it’s called from a static initializer, the failure is permanent.

Normally it should be OK for Quartz to start when services start. Normally the jobs it runs are part of the service layer. This happens to be a weird case where the service level has a dependency upon the tool level.

We can modify the Samigo job to not run unless it can get to the tool layer. However I think it would be better to delay the startup of Quartz until Sakai is fully up.

My thought was to modify the init for Quartz to lazy-init, and then add an explicit dependency to something started very late in startup. However I can’t find anything appropriate. Portal seems to start last, but it doesn’t seem to use Spring. Can anyone think of a Spring configuration that’s done near the end? Another approach would be to call the init explicitly from the portal init code. That may be what I end up doing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20150120/08e9ac69/attachment.html