Running war on tomcat7 vs grails run-app

Question

I am having a problem running grails generated war file on tomcat7. If/when I run the same app with grails run-app all is good and in the proper working order. The exception I get while running tomcat7 and deployed war:

2014-08-20 09:17:28,933 [http-bio-127.0.0.1-8080-exec-7] ERROR errors.GrailsExceptionResolver  - ClassNotFoundException occurred when processing request: [GET] /
jline.console.history.History. Stacktrace follows:
java.lang.ClassNotFoundException: jline.console.history.History
    at org.codehaus.plugin.swagger.builder.SwaggerDocsBuilder.buildApiDeclarations(SwaggerDocsBuilder.groovy:71)
    at org.codehaus.plugin.swagger.builder.SwaggerDocsBuilder.rebuild(SwaggerDocsBuilder.groovy:48)
    at org.codehaus.plugin.swagger.builder.SwaggerDocsBuilder.build(SwaggerDocsBuilder.groovy:36)
    at org.codehaus.grails.plugins.swaggerapidocs.SwaggerApiDocsController.resources(SwaggerApiDocsController.groovy:21)
    at grails.plugin.cache.web.filter.PageFragmentCachingFilter.doFilter(PageFragmentCachingFilter.java:198)
    at grails.plugin.cache.web.filter.AbstractFilter.doFilter(AbstractFilter.java:63)
    at com.brandseye.cors.CorsFilter.doFilter(CorsFilter.java:82)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

Line 71 of SwaggerDocsBuilder.groovy

rules = new BuildPathMap().build(grailsApp)

and BuildPathMap extends

import org.codehaus.groovy.grails.web.mapping.reporting.AnsiConsoleUrlMappingsRenderer
class BuildPathMap extends AnsiConsoleUrlMappingsRenderer {

my guess is AnsiConsoleUrlMappingsRenderer somehow depends on jline.console.history.History but then why is it missing from the war file? Is there something that can be done during the war generation to ensure that ll dependencies are properly packaged?

Hey @ash can you please validate if my answer is correct ? – Milind J May 25 '15 at 00:32 — Milind J, May 25 '15 at 00:32

Milind J · Answer 1 · 2015-05-25T00:31:33.450

3

Its a bug in grails.

https://jira.grails.org/browse/GRAILS-8532

could fix this with a workaround adding the following snippet to BuildConfig.groovy:

grails.war.resources = { stagingDir, args ->
    copy(todir: "${stagingDir}/WEB-INF/lib", flatten: "true") {
        fileset(dir: "${grailsHome}/lib", includes: "**/jline-*.jar, **/jansi-*.jar")
    }
}

edited May 25 '15 at 00:31

answered Mar 06 '15 at 00:52

Milind J

529
5
10

Worked for me, thanks. The JIRA link doesn't though. – John M Apr 17 '16 at 17:50
1

Yeah the JIRA is not working, they migrated it. I stopped using Grails anyways. – Milind J Apr 27 '16 at 06:24

score 2 · Answer 2 · answered Apr 01 '16 at 16:12

2

Not sure if this is the best solution, but I was able to get around this problem by explicitly adding a jLine dependency in BuildConfig.groovy:

runtime 'jline:jline:2.12'

I did not see this error with Grails 2.5.1, but did with Grails 2.5.4. Seems like a bug.

answered Apr 01 '16 at 16:12

augustearth

281
2
10

Same here, only appeared when upgrading from 2.5.1 to 2.5.4. – John M Apr 17 '16 at 17:52

Joe · Answer 3 · 2014-08-20T16:27:24.107

0

Is your Tomcat configured to run an unpacked or packed war. Development runs as an unpacked war so commands like servlet.getRealPath() return a valid value when running that on a packed war the Tomcat servlet container returns null. In the server.xml search for unpackWARs attribute.

  <Host name="localhost"  appBase="webapps"
        unpackWARs="false" autoDeploy="false">

Also some dependencies are added for you when running in development and you need to specify them in the BuildConfig.groovy otherwise they may not be available in the war.

edited Aug 20 '14 at 16:27

answered Aug 20 '14 at 16:20

Joe

951
6
13

– ash Aug 20 '14 at 17:16
"Also some dependencies are added for you when running in development and you need to specify them in the BuildConfig.groovy otherwise they may not be available in the war." - this is something that I find odd but it sure seems like it is the case. Is there a way to prevent this from happening, so in my development I can prevent problems that might occur in production? – ash Aug 20 '14 at 17:18

Running war on tomcat7 vs grails run-app

3 Answers3