What maven-jetty-plugin 8 configuration allows reloading of JSP files when they change?

Question

Consider a default webapp configuration in Maven (for the test case I used struts2-blank-archetype from https://repository.apache.org/content/groups/public/archetype-catalog.xml ).

This archetype comes with maven jetty plugin's version 6. With the configuration below, if I change a jsp under /src/main/webapp/WEB-INF/ and save it, refreshing the browser will show these changes.

        <plugin>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>maven-jetty-plugin</artifactId>
            <version>6.1.21</version>
            <configuration>
                <scanIntervalSeconds>10</scanIntervalSeconds>
            </configuration>
        </plugin>

(notice that one doesn't even need to put the scantarget element, as we don't want a complete container reload when you just change a jsp).

However, the exact same configuration of version 8 of the plugin (see below) does not work. If I change the same jsp, refreshing the browser will show the old JSP contents. Only by stopping and starting the server will I see the changes.

        <plugin>
            <groupId>org.mortbay.jetty</groupId>
             <artifactId>jetty-maven-plugin</artifactId>
             <version>8.1.7.v20120910</version>
            <configuration>
                <scanIntervalSeconds>10</scanIntervalSeconds>
            </configuration>
        </plugin>

What is wrong with this configuration, and what configuration would produce the same results in version 8 (ie, auto-refreshing the jsp contents without restarting the server)?

EDIT: Here's a 2 minute test you can try:

1. Create archetype struts2-archetype-convention ("mvn archetype:generate", 308, package war).
2. Edit the pom and set the jetty plugin configuration to the one listed above (version 6)
3. mvn jetty:run
4. Open the browser on "http://localhost:8080"
5. See "Languages" on the page
6. Edit /src/main/webapp/WEB-INF/content/hello.jsp - change "Languages" for something else. Save.
7. Refresh the browser and see the change.
8. Repeat the steps. On step 2, change the artifactId and version to the ones listed above (version 8)
9. Confirm the webpage does not change upon refresh after you perform the change in the JSP.

Answer 1

There have been a host of improvements to the plugin since jetty-6 days to run a variety of different project configurations. Take a look at the documentation page for the plugin, choose the scenario that best meets you needs and adapt the configuration as needed. I suspect your case is under 'Running an unassembled webapp'.

http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin

I'll note that for jetty-9 we are finally bringing the plugin over to eclipse so it can live with the project which will change the groupId to org.eclipse.jetty, the jetty-maven-plugin for 9.0.0.M2 will be in central early next week (documentation to be updated for that as well still)

cheers

Answer 2

mmalmeida, I've tested this scenario using the standard jetty-test-webapp. I put a jsp in src/main/webapp/jsp that forwards to another jsp in src/main/webapp/WEB-INF. Starting the jetty maven plugin with mvn jetty:run, the forward happens correctly. If I leave the plugin running and modify the jsp in WEB-INF, and do a shift-reload on the browser, it picks up the changed page as expected.

Note that you do not need to declare scanTargets or anything else of that nature. The above behaviour (jsp reload) is a function of the jsp engine, which when running in development mode will check the timestamps on jsp files as it receives requests, and recompile on the fly as necessary.

I think you'll have to provide more details about your specific webapp - in particular how your setup is different to the test scenario I just described - in order to get any further with this.

regards Jan

Answer 3

After the previous comments I was able to identify the root cause of this issue. While this is a bit specific to our use case, I share this with the community nonetheless.

This is basically caused by the timestamps of the files. My work directory is an NFS mount of another server. For some strange reason* the clock on that server is delayed. This means that if it's 9:00 and I change the JSP file, the file will be timestamped with 8:40.

There might have been a change in Jetty from 6 to 8 regarding the strategy used for JSP file reloading - while Jetty 6 does not seem to care about the file's timestamp and refreshes anyway, Jetty 8 is more sensitive and does not reload the file.

So the "solution" here was simply to update the remote NFS server's clock.

*meaning the NTP deamon is running, I can ping the ntp servers, other machines on the same networks have the same NTP settings and yet this machine is still having its clock drift