groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Wagenleitner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-8294) Return 404 for non-existing paths in `TemplateServlet` when running from .war
Date Fri, 25 Aug 2017 01:43:00 GMT

    [ https://issues.apache.org/jira/browse/GROOVY-8294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141050#comment-16141050
] 

John Wagenleitner commented on GROOVY-8294:
-------------------------------------------

I labelled as {{breaking}} just to call out the change in behavior, but think it does fix
a bug and should go in the next 2.4.x release.

> Return 404 for non-existing paths in `TemplateServlet` when running from .war
> -----------------------------------------------------------------------------
>
>                 Key: GROOVY-8294
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8294
>             Project: Groovy
>          Issue Type: Bug
>         Environment: Payara Micro
>            Reporter: Thomas Reifenberger
>              Labels: breaking
>         Attachments: broken-template-servlet.tar.gz
>
>
> When TemplateServlet is used in application servers that don't unpack a war (i.e. when
the real path of resources could not be retrieved), an internal server error is returned upon
trying to retrieve a non-existing template file.
> The expected behavior would be to get a 404, just as it is already the case when running
from a extracted war.
> I had this behavior when running on a [payara micro|https://www.payara.fish/payara_micro]
application server using the following {{web.xml}} snippet:
> {code}
> <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5">
>     <servlet>
>         <servlet-name>GroovyTemplate</servlet-name>
>         <servlet-class>groovy.servlet.TemplateServlet</servlet-class>
>     </servlet>
>     <servlet-mapping>
>         <servlet-name>GroovyTemplate</servlet-name>
>         <url-pattern>*.gsp</url-pattern>
>     </servlet-mapping>
> </web-app>
> {code}
> and requesting an url ending in {{*.gsp}}, but without a template with that name present.
> Please see the attached minimal example (docker required):
> Run it with:
> {code}
> ./gradlew runDockerContainer
> {code}
> and test the URLs
> http://localhost:8080/test.gsp  (works)
> http://localhost:8080/unknown.gsp  (500, but I would actually expect a 404)
> The corresponding stacktrace is
> {code}
> java.lang.NullPointerException
>         at groovy.servlet.TemplateServlet.getTemplate(TemplateServlet.java:331)
>         at groovy.servlet.TemplateServlet.service(TemplateServlet.java:445)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>         at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1606)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:258)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:160)
>         at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:654)
>         at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:593)
>         at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:99)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
>         at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:371)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:238)
>         at com.sun.enterprise.v3.services.impl.ContainerMapper$HttpHandlerCallable.call(ContainerMapper.java:466)
>         at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:169)
>         at org.glassfish.grizzly.http.server.HttpHandler.runService(HttpHandler.java:206)
>         at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:180)
>         at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:235)
>         at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
>         at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
>         at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
>         at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
>         at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
>         at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
>         at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539)
>         at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
>         at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
>         at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
>         at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
>         at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593)
>         at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573)
>         at java.lang.Thread.run(Thread.java:745)
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message