Running a war file doesn't work if it has a path

[xpusostomos]

Just wasted a few days of my life trying to figure out why a war file won't run....

This doesn't work...

java -Dgrails.env=development -jar build/libs/myapp.war

If you do it, grails won't be able to find your view files.

This will work...

(cd build/libs ; java -Dgrails.env=development -jar myapp.war )

This really should work as expected... however at the very least, if it can't support the correct behavior, it should exit gracefully with a meanful error message rather than starting up tomcat, but misbehaving.

This issue seems to have come up before, but it didn't seem as if people understood that the problem is related to having a path on the command line:

#605

and I'm not the first one to be confused about what is wrong:

https://stackoverflow.com/questions/37863465/how-to-run-grails-3-1-x-application-with-java

Here is some stack trace from when it fails...

2021-11-09 17:29:57.687 ERROR --- [nio-8083-exec-2] .a.c.c.C.[.[.[.[grailsDispatcherServlet] : Servlet.service() for servlet [grailsDispatcherServlet] in context with path [/living-collection] threw exception [Could not resolve view with name 'search' in servlet with name 'grailsDispatcherServlet'] with root cause
javax.servlet.ServletException: Could not resolve view with name 'search' in servlet with name 'grailsDispatcherServlet'
        at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1352)
        at org.springframework.web.servlet.DispatcherServlet.processDispatchResult(DispatcherServlet.java:1118)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1057)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
        at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:626)
        at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
        at org.springframework.boot.actuate.web.trace.servlet.HttpTraceFilter.doFilterInternal(HttpTraceFilter.java:88)
        at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)

grails 4.0.12

[jeffscottbrown]

@xpusostomos Does the following work for you?

~ $ git clone git@github.com:jeffbrown/xpusotomosrunwar.git
Cloning into 'xpusotomosrunwar'...
remote: Enumerating objects: 104, done.
remote: Counting objects: 100% (104/104), done.
remote: Compressing objects: 100% (84/84), done.
remote: Total 104 (delta 10), reused 104 (delta 10), pack-reused 0
Receiving objects: 100% (104/104), 627.50 KiB | 1.91 MiB/s, done.
Resolving deltas: 100% (10/10), done.
~ $ 
~ $ 
~ $ cd xpusotomosrunwar 
xpusotomosrunwar (main)$ 
xpusotomosrunwar (main)$ ./gradlew assemble

BUILD SUCCESSFUL in 9s
7 actionable tasks: 7 executed
xpusotomosrunwar (main)$ java -jar -Dgrails.env=development build/libs/xpusotomosrunwar-0.1.war
Grails application running at http://localhost:8080 in environment: development

[jeffscottbrown]

I think I see now. The app probably starts fine and request process leads to problems. Is that the case?

[jeffscottbrown]

I have added the info: example-attached. The project I linked in a previous comment demonstrates the behavior described in the question.

[xpusostomos]

Yes, it fails when you actually access a view.