Reloadable isnt working with tomcat7

[nspessot]

Hi, I have set up gradle tomcat plugin to my project, I followed this tutorial to made it works but for some reason after modifying a java class and running gradle compileJava tomcat does not reload. I am using Spring tool suite as my IDE, but I execute gradle task using windows command line.

Here is my build.gradle file:

apply plugin: 'war' apply plugin: 'tomcat' apply plugin: 'java' apply plugin: 'propdeps' apply plugin: 'propdeps-maven' apply plugin: 'propdeps-idea' apply plugin: 'propdeps-eclipse' apply plugin: 'eclipse' apply plugin: 'idea'

buildscript { repositories { mavenCentral() maven { url "http://download.java.net/maven/2" } maven { url 'http://repo.spring.io/plugins-release' } jcenter() }

dependencies { classpath 'org.gradle.api.plugins:gradle-tomcat-plugin:1.0' classpath 'org.springframework.build.gradle:propdeps-plugin:0.0.1' } }

repositories { mavenCentral() maven { url 'http://repo.spring.io/milestone/' } maven { url 'http://www.hibernatespatial.org/repository' } maven { url 'http://download.osgeo.org/webdav/geotools' } }

jar { baseName = 'location-backend' version = '0.1.0' }

repositories { mavenCentral() }

dependencies {

def tomcatVersion = '7.0.42'
tomcat "org.apache.tomcat.embed:tomcat-embed-core:${tomcatVersion}",
        "org.apache.tomcat.embed:tomcat-embed-logging-juli:${tomcatVersion}"
tomcat("org.apache.tomcat.embed:tomcat-embed-jasper:${tomcatVersion}") {
  exclude group: 'org.eclipse.jdt.core.compiler', module: 'ecj'
}

providedCompile 'javax.servlet:javax.servlet-api:3.1.0',
                'javax.servlet:jsp-api:2.0'

}

[tomcatRun, tomcatRunWar, tomcatStop].stopPort = 8081 [tomcatRun, tomcatStop].stopKey = 'stopKey'

tomcatRun { httpPort = 8080 httpsPort = 8443 enableSSL = true reloadable = true }

task wrapper(type: Wrapper) { gradleVersion = '1.9' }

tomcatRunWar.contextPath = ''

[bmuschko]

What's the task you are using to run Tomcat - tomcatRun or tomcatRunWar? Do you have a sample project on GitHub that demonstrates the issue?

[nspessot]

Hi Benjamin, I don't have a such project on GitHub, but if you need I can try to upload one. The issue is happening even if I run using tomcatRun or tomcatRunWar, with both task I have the same problem.

To recreate the issue I just change a java file from eclipse and then wait for a while, let say one minute and then I test with the browser but I dont see the change. Do I need to run a gradle task after that?

[Emontis]

You're supposed to run gradle compileJava again but even then reloading does not work for us.

[masvboston]

I'm actually experiencing the same problem. I have a simple Jersey WebApp I built to test it out. The README.txt has the instructions. Here is the link to the simple Jersey example code:

https://github.com/masvboston/adhoc-repo/tree/master

Thanks for the useful plugin and thanks in advance for the help on figuring out why the hot reload is not working.

Mark

[zachlendon]

I am experiencing the same issues as those above, Tomcat 7, gradle compile, class files are updated on file system, no reload happening. Just trying a simple println. With our without a context.xml, reloadable explicitly or not explicitly set to true.

[bmuschko]

Is anyone of you interested in looking into this issue? I'd love to get this fixed as soon as possible.

[zachlendon]

I will look into it.

[bmuschko]

@zachlendon Thanks for that. I know that it was working at some point of time. Have a look at this issue. It indicates that it was working with plugin version 0.9.7 (the code is tagged so you can compare it with master) and Tomcat 7.0.30. There's also an example project you can check.

[bmuschko]

Seems like this only works if you send the compiled class files to the default web application classes directory:

sourceSets.main.output.classesDir = file('webapp/WEB-INF/classes')

[masvboston]

OK,

Does that imply the code is not picking up the output directory from the configuration? So sorry I can't be more helpful. I'm new to groovy, gradle, and the project I'm currently on that's eating all my time. I greatly appreciate your efforts.

Mark On Mar 8, 2014 10:17 AM, "Benjamin Muschko" [email protected] wrote:

Seems like this only works if you send the compiled class files to the default web application classes directory:

sourceSets.main.output.classesDir = file('webapp/WEB-INF/classes')

Reply to this email directly or view it on GitHubhttps://github.com/bmuschko/gradle-tomcat-plugin/issues/81#issuecomment-37099886 .

[bmuschko]

@masvboston That means that the embedded container implementation either only looks for changes in the default location WEB-INF/classes or the plugin does not configure the location correctly. Unfortunately, Tomcat's Javadoc is not necessarily very helpful.

[masvboston]

Hmmmmm. OK. Understood. On Mar 10, 2014 9:37 PM, "Benjamin Muschko" [email protected] wrote:

@masvboston https://github.com/masvboston That means that the embedded container implementation either only looks for changes in the default location WEB-INF/classes or the plugin does not configure the location correctly. Unfortunately, Tomcat's Javadoc is not necessarily very helpful.

Reply to this email directly or view it on GitHubhttps://github.com/bmuschko/gradle-tomcat-plugin/issues/81#issuecomment-37255076 .

[zachlendon]

Thanks Benjamin for the research tidbits. They've helped - I've looked at the sample project and actually created one of my own. I've also done a brief lookover of both this plugin's source and Tomcat 7.0.52's source code, in respect to 'reloadable'. I didn't see anything glaring in this plugin or Tomcat's source that made me think the general approach we were attempting to follow was incorrect.

As a result of this initial analysis, I've since had a little time to test some scenarios out with a simple Java Spring MVC app running on Tomcat 7.0.30 via this gradle plugin (I have yet to test 7.0.11 - as the current docs show as the version to use). Here's what I've seen so far:

If your webapp structure is the standard: 'src/main/webapp' (and thus src/main/java), then reloadable works if you define the following (which is indeed required):

sourceSets.output.classesDir = 'src/main/webapp/WEB-INF/classes'

In this scenario you don't need to also define a tomcatRun.webAppSourceDirectory, as the above is the default. However, if, for example, you had your 'webapp' folder under the root of the project, as the sample project in this issue: https://github.com/bmuschko/gradle-tomcat-plugin/issues/40 did - namely this project: https://github.com/vladvoic/tomcatGradleExample, then you do need to not only define:

sourceSets.output.classesDir = 'webapp/WEB-INF/classes'

but also: tomcatRun.webAppSourceDirectory = file('webapp')

Finally, I'm also seeing that there are no indications in the logs, at the default logging level at least, that the reload has actually occurred. But I can see that it has when reloading my test app in the browser.

One final note for those looking at these comments in the future - remember that only certain changes are 'reloadable' via JVM Hot Swap. If you're adding/removing methods/classes or changing an object hierarchy and don't see changes, then you may just have to do a restart or use a product like JRebel (which I've had success with also using the instructions provided on this plugin's readme).

Armed with this preliminary data, I'm going to go back to my bigger app and test it out to see if I can get reloading working. I should be able to update this ticket with those results within 48 hours.

[bmuschko]

@zachlendon Thanks for taking the time to look into this.

[bmuschko]

@zachlendon Were you able to make any more progress in the meantime on this?

[zachlendon]

Beyond the simpler use cases I outlined in my prior response, I couldn't get reloading working in the larger app I referenced. The team for that app has the option to use JRebel, which proved satisfactory. That app required it's own context.xml for other reasons, and in the end there were just too many standard deviations from what might be a 'typical implementation' to go down the rabbit hole and figure out why reloading wasn't working.

While I obviously defer to you @bmuschko, my proposal for this issue would be to close this issue and if people still have reloading issues, to encourage them to post the simplest app they can that replicates the issue. Presuming the issue was deemed worthy of fixing, I'd be more than willing to pitch in on those samples to help resolve them.

[firesh]

Is there any update on this issue. I have same problem which reloadable is not working. I have to go back with Jetty for hot code deployment.

[bmuschko]

@firesh No update. I am waiting for external contributions for this. Want to look into it?

[chenrui333]

Any update on this issue?

[bmuschko]

Closing as issue got no traction.