A follow-up on this. 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 was 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. Why the NTP-aware server is having trouble with the time is another issue... Miguel Almeida On Tue, 2012-11-06 at 13:12 +0100, Lukasz Lenart wrote: > 2012/10/31 Miguel Almeida <mig...@almeida.at> > > > Hey Lukasz, > > > > Does your jetty configuration match the ones I provided? More > > specifically, did you remove the <scanTargets> element? With > > scanTargets you will see the JSP changes, but only after the automatic > > container reload (so, worse case scenario in 10 seconds, as defined in > > the <scanIntervalSeconds> element. > > > > If you remove scanTargets, the page will not be refreshed on JSP change > > in jetty 8 but will be refreshed in jetty 6! And reloading the entire > > container for every JSP change seems like an overkill (and slows down > > development process considerably when your webapp has session variables > > and security). > > > > Could you try the configuration without <scanTargets> for jetty 6 and 8? > > > Yes, I did that and even committed the change [1], there was no Jetty > restarts when I've been changing jsp file. > > [1] https://issues.apache.org/jira/browse/WW-3916 > > > Regards