Ran into an interesting situation in our production servers today. We’ve been sending out e-mail asynchronously locally without any issues. As soon as we put the code into production we started to see the following errors:
org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.NoClassDefFoundError: org/springframework/mock/web/MockHttpServletRequest
at BackgroundThreadManager$1.run(BackgroundThreadManager.java:90)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NoClassDefFoundError: org/springframework/mock/web/MockHttpServletRequest
at grails.util.GrailsWebUtil.bindMockWebRequest(GrailsWebUtil.java:58)
at grails.util.GrailsWebUtil$bindMockWebRequest.call(Unknown Source)
at org.grails.mail.MailMessageBuilder.renderMailView(MailMessageBuilder.groovy:206)
at org.grails.mail.MailMessageBuilder.body(MailMessageBuilder.groovy:137)
From past experience with Spring I knew the spring-test jar file contains the Mock classes. I didn’t realize until digging into the mail plugin that it was used to help render views. The code used in the plugin is as follows. It appears to use the MockHttpServletRequest where there isn’t a real HttpServletRequest (like in a background thread or scheduled with Quartz). The MockHttpServletRequest allows the mail plugin to still find you view templates and use them outside the scope of a real request, that’s pretty handy.
if(!requestAttributes) {
def servletContext = ServletContextHolder.getServletContext()
def applicationContext = WebApplicationContextUtils.getRequiredWebApplicationContext(servletContext)
requestAttributes = GrailsWebUtil.bindMockWebRequest(applicationContext)
unbindRequest = true
}
After scratching my head for a while I simply copied the jar file in $GRAILS_HOME/lib/org.springframework.test-3.0.0.RELEASE.jar into my local application directory and all was well again. I also stumbled on this JIRA issue referencing the same problem, and another solution.
http://jira.codehaus.org/browse/GRAILSPLUGINS-1885
