tomcatRun and Spring's @RequestMapping

[djKianoosh]

First of all, great plugin!

I thought you should know of a problem I'm having with the tomcatRun task and a Spring based Controller annotated with @RequestMapping that doesn't seem to get spun up right.

I'm playing with this spring-backbone example which had a maven build. I converted it over to a gradle build and everything works nice with gradle war and deploying the war manually to tomcat. It's a very simple todo app. When using your plugin, tomcatRun does run the main webapp under localhost:8080/todo, but there's another config in the TodoController that gets configured like this:

public class TodoController {

So this should be available at http://localhost:8080/todo/api/todo but it doesn't get wired up properly when using gradle tomcatRun. Like I said it does work with gradle war and deploying it to tomcat manually. Would be nice for tomcatRun to work though

FYI I run it with --info and --stacktrace but there's no exception. Running it with --debug has crazy neverending amounts of output in the console. That would take longer :)

[bmuschko]

Thanks, I am glad you find the plugin useful. It's good you are letting me know about this issue.

I personally haven't used the new Spring 3.1 MVC features yet but based on the documentation it looks like they do some special things with the default web.xml.

The caveat to overriding the "/" Servlet mapping is that the RequestDispatcher for the default Servlet must be retrieved by name rather than by path. The DefaultServletHttpRequestHandler will attempt to auto-detect the default Servlet for the container at startup time, using a list of known names for most of the major Servlet containers (including Tomcat, Jetty, Glassfish, JBoss, Resin, WebLogic, and WebSphere). If the default Servlet has been custom configured with a different name, or if a different Servlet container is being used where the default Servlet name is unknown, then the default Servlet's name must be explicitly provided.

I guess this works fine if you deploy it to an installed container because it provides its default web.xml. The Tomcat Gradle plugin uses an embedded Tomcat container implementation instead. I'd have to check both Tomcat and Spring implementations to see what the default Servlet gets registered with and see if I can make this work. I already have a convention property in place that lets you set the default web.xml so I guess that will be the key to making it work.

FYI: I tried out the Gradle Jetty plugin and couldn't get it running right away as well.

[tinhtruong]

I want to add some more details to this issue with my findings on version 0.8.1. My Spring MVC 3.1 web app does not have web.xml file (Servlet 3.0). I can tomcatRunWar (@RequestMapping work perfectly) with my application but cannot with tomcatRun (the behavior is the same as djKianoosh described).

[bmuschko]

Thanks for your feedback @tinhtruong. Unfortunately, I couldn't get @djKianoosh's application running with tomcatRunWar either. The console output is certainly different though. I will have to further investigate on this.

@tinhtruong: Do you have your app publicly available?

[sdeleuze]

Same issue here, also on spring-backbone example application.

What is strange is that classpath scanning occured (typical stratup lag) but I got the following message :

No global web.xml found No Spring WebApplicationInitializer types detected on classpath

I hope somebody will be able to fix this bug ...

[bmuschko]

I believe this to be a bug in the embedded Tomcat container implementation. Please check this issue I created. Looks like I need to provide a test case. I will try to set up a test project for them soon.

[sdeleuze]

Perhaps an information that can help : it works with t7mp Maven plugin (http://t7mp.github.com/) with the Spring 3.1 Backbone example application https://github.com/sdeleuze/spring-backbone-todo. I think it use also the embedded Tomcat, but perhaps in another way ...

[cbeams]

See my comments on the bugzilla issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=52853#c11

They basically echo @sdeleuze, giving a different working example of the tomcat7-maven-plugin deploying a web.xml-free Spring 3.1 app without any problem.

[sdeleuze]

I have updated the sample yesterday in order to make it work also is Maven Jetty plugin. I think it could make it work also with the Gradle Tomcat plugin, I will test and send a feedback shortly.

For information, I had to provide a custom empty web.xml in order to override Jetty webdefault.xml that contained a dispatcher that conflicted with the one declared in Java code + a fix in the WebApplicationInitializer.

Related changeset is here : https://github.com/sdeleuze/spring-backbone-todo/commit/9e4d65cde3555dc0ee80eb8744b166c0db0c5277

[bmuschko]

It would be great if you could provide a pull request. As far as I understood the spec you don't need to provide an empty web.xml. But if that's what it takes to make it work for now I'd be happy with it. I think this empty web.xml would have to be generated on-the-fly. Thanks for the pointer. I won't have time this weekend to have a look at it but I might have some room next week.

[bmuschko]

I tried to use an empty web.xml but that doesn't seem to make it work. Apparently, the behavior is different from Jetty. This is what I tried:

tomcatRun.webDefaultXml = file('web.xml')

After checked the Maven plugin I found this patch. I played around with this a bit but couldn't achieve the result we are aiming for. However, I finished up my test cases for the Tomcat guys so hopefully they will have a look at this issue now and give me the correct advice to make it work.

[bmuschko]

This is fixed with version 0.9.2.

[cbeams]

That's great news, Benjamin. Thanks!

[sdeleuze]

Thanks !