Jetty
  1. Jetty
  2. JETTY-1243

jetty:run seems to not notice changes to templates inside WEB-INF in your web app if you are using a war overlay

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 7.1.4
    • Fix Version/s: 7.0.2
    • Component/s: Maven
    • Labels:
      None
    • Number of attachments :
      1

      Description

      when using web apps using war overlays (e.g. one of the samples in Scalate which reuses the scalate console using an overlay), changing templates don't seem to get recognised in jetty:run. To re-evaluate a template you have to stop & restart "mvn jetty:run"!

      However if we zap the redundant copy of the source templates from src/main/webapp which get copied into target/tmp/webinf/WEB-INF/ then it all works fine.

      The question is, since the source of target/tmp/webinf/WEB-INF is all available in src/main/webapp/WEB-INF - why does the maven plugin make a redundant copy when using overlays - that then breaks reloading.

      Maybe it needs to only copy stuff to target/tmp/webinf/WEB-INF if there is not a file of the same name in src/main/webapp/WEB-INF? i.e. delete the stuff from the overlay which exists in src/main/webapp/WEB-INF?

        Issue Links

          Activity

          Hide
          james strachan added a comment -

          if you're interested in a little sample project to play with to demonstrate this, grab scalate...

          http://scalate.fusesource.org/source.html

          git clone git://github.com/scalate/scalate.git
          cd scalate
          

          its probably safest to do a build first
          http://scalate.fusesource.org/building.html

          then do

          cd scalate-sample
          mvn jetty:run
          

          now view

          http://localhost:8080/foo.ssp

          now try editing

          scalate-sample/src/main/webapp/WEB-INF/foo.ssp

          reload the browser - see how its not detected the changed template file?

          If you do

           rm scalate-sample/target/tmp/webinf/WEB-INF/foo.ssp 
          

          now do a reload in your browser. Hey presto - the template is now reloaded.

          Bsaically Jetty is serving up the copy it made of the source on startup in target/tmp/webinf/WEB-INF/ rather than looking in src/main/webapp/WEB-INF

          Show
          james strachan added a comment - if you're interested in a little sample project to play with to demonstrate this, grab scalate... http://scalate.fusesource.org/source.html git clone git: //github.com/scalate/scalate.git cd scalate its probably safest to do a build first http://scalate.fusesource.org/building.html then do cd scalate-sample mvn jetty:run now view http://localhost:8080/foo.ssp now try editing scalate-sample/src/main/webapp/WEB-INF/foo.ssp reload the browser - see how its not detected the changed template file? If you do rm scalate-sample/target/tmp/webinf/WEB-INF/foo.ssp now do a reload in your browser. Hey presto - the template is now reloaded. Bsaically Jetty is serving up the copy it made of the source on startup in target/tmp/webinf/WEB-INF/ rather than looking in src/main/webapp/WEB-INF
          Hide
          james strachan added a comment -

          I wonder if the fix for this could be so simple as to get jetty to look in src/main/webapp before target/tmp/webinf from the overlay?

          Show
          james strachan added a comment - I wonder if the fix for this could be so simple as to get jetty to look in src/main/webapp before target/tmp/webinf from the overlay?
          Hide
          Jan Bartel added a comment -

          James,

          In your jetty plugin configuration, can you try setting the resourceBase for the webapp to be the directory you want to take precedence (is it src/main/webapp ?). Something like:
          <webAppConfig>
          <resourceBase>$

          {basedir}

          /src/main/webapp</resourceBase>
          </webAppConfig>

          That should mean that the overlays get added after the <resourceBase>.

          Lemme know if that doesn't work.

          cheers
          Jan

          Show
          Jan Bartel added a comment - James, In your jetty plugin configuration, can you try setting the resourceBase for the webapp to be the directory you want to take precedence (is it src/main/webapp ?). Something like: <webAppConfig> <resourceBase>$ {basedir} /src/main/webapp</resourceBase> </webAppConfig> That should mean that the overlays get added after the <resourceBase>. Lemme know if that doesn't work. cheers Jan
          Hide
          james strachan added a comment -

          thanks Jan - I'll give that a try.

          as an aside I've just been trying to upgrade from 7.0.1.v20091125 to 7.1.4.v20100610 and am having some other issues - will report back ASAP once I've upgraded and tried out your configuration idea!

          Show
          james strachan added a comment - thanks Jan - I'll give that a try. as an aside I've just been trying to upgrade from 7.0.1.v20091125 to 7.1.4.v20100610 and am having some other issues - will report back ASAP once I've upgraded and tried out your configuration idea!
          Hide
          james strachan added a comment -

          Hmm - seems in 7.1.4.v20100610 jetty:run only expands the WEB-INF/lib and WEB-INF/classes directories into target/tmp/webinf/WEB-INF. So none of my shared templates from the overlay in WEB-INF/* are used in "mvn jetty:run". I'm gonna go hunting around to see if there's a way to get jetty:run to reuse all the WEB-INF contents...

          Show
          james strachan added a comment - Hmm - seems in 7.1.4.v20100610 jetty:run only expands the WEB-INF/lib and WEB-INF/classes directories into target/tmp/webinf/WEB-INF. So none of my shared templates from the overlay in WEB-INF/* are used in "mvn jetty:run". I'm gonna go hunting around to see if there's a way to get jetty:run to reuse all the WEB-INF contents...
          Hide
          james strachan added a comment -

          So it seems from 7.0.2.v20100331 onwards, "jetty:run" only considers WEB-INF/classes and WEB-INF/lib to be part of the overlay - everything else in WEB-INF is ignored.

          This is different behaviour to both "mvn war" and "mvn jetty:run-war" which includes everything inside WEB-INF in the overlay. So this sounds like jetty:run is broken from 7.0.2.x onwards for overlays using WEB-INF. FWIW we've been following the practice of putting templates inside WEB-INF in various directories so that the templates are not visible directly - but only internally inside servlets/filters/jaxrs etc.

          I wonder why everything inside WEB-INF is ignored for jetty:run? Maybe this change was a work around to ordering issues like I originally reported in this issue - that with overlays, jetty:run seems to prefer to use the copies of files in target/tmp/webinf over the source code?

          Show
          james strachan added a comment - So it seems from 7.0.2.v20100331 onwards, "jetty:run" only considers WEB-INF/classes and WEB-INF/lib to be part of the overlay - everything else in WEB-INF is ignored. This is different behaviour to both "mvn war" and "mvn jetty:run-war" which includes everything inside WEB-INF in the overlay. So this sounds like jetty:run is broken from 7.0.2.x onwards for overlays using WEB-INF. FWIW we've been following the practice of putting templates inside WEB-INF in various directories so that the templates are not visible directly - but only internally inside servlets/filters/jaxrs etc. I wonder why everything inside WEB-INF is ignored for jetty:run? Maybe this change was a work around to ordering issues like I originally reported in this issue - that with overlays, jetty:run seems to prefer to use the copies of files in target/tmp/webinf over the source code?
          Hide
          james strachan added a comment -

          Hi Jan

          I tried your workaround (its in the scalate master if you fancy a looksie) but unfortunately it has the same effect - the issue is still there.

          So I'm faced with either reload not working on 7.0.1.x - or overlays not working in 7.0.2.x or later.

          Show
          james strachan added a comment - Hi Jan I tried your workaround (its in the scalate master if you fancy a looksie) but unfortunately it has the same effect - the issue is still there. So I'm faced with either reload not working on 7.0.1.x - or overlays not working in 7.0.2.x or later.
          Hide
          Jan Bartel added a comment -

          James,

          You had me going there for a minute. I could have sworn I had fixed this problem back in 7.0.2, so I was surprised to see it pop up again. Actually, I did fix it!

          Here's the reference to the previous issue you raised that I fixed: http://jira.codehaus.org/browse/JETTY-1027

          So all you need to do is to add the following to your <webAppConfig> element:

          <unpackOverlays>true</unpackOverlays>

          I'm uploading a little test webapp that shows the unpack of the overlays works. If you build it, then go to example-webapp/other-webapp and do mvn jetty:run, and hit http://localhost:8080/test/foo, the servlet will print out on stderr where the foo.foo file real path was found. Rename example-webapp/other-webapp/src/main/webapp/WEB-INF/foo.foo to something else and rerun and you'll see the one from the my-webapp war is used instead.

          cheers
          Jan

          Show
          Jan Bartel added a comment - James, You had me going there for a minute. I could have sworn I had fixed this problem back in 7.0.2, so I was surprised to see it pop up again. Actually, I did fix it! Here's the reference to the previous issue you raised that I fixed: http://jira.codehaus.org/browse/JETTY-1027 So all you need to do is to add the following to your <webAppConfig> element: <unpackOverlays>true</unpackOverlays> I'm uploading a little test webapp that shows the unpack of the overlays works. If you build it, then go to example-webapp/other-webapp and do mvn jetty:run, and hit http://localhost:8080/test/foo , the servlet will print out on stderr where the foo.foo file real path was found. Rename example-webapp/other-webapp/src/main/webapp/WEB-INF/foo.foo to something else and rerun and you'll see the one from the my-webapp war is used instead. cheers Jan
          Hide
          Jan Bartel added a comment -

          Example webapp that uses resources inside overlayed wars.

          Show
          Jan Bartel added a comment - Example webapp that uses resources inside overlayed wars.
          Hide
          james strachan added a comment -

          I'm so sorry Jan! I'd actually missed your comment on JETTY-1027 - and thought this was a different issue connected to Jetty picking up the wrong file, rather than overlays not working with jetty:run. DOH! Sorry again - dinner on me next time we meet!

          I've tried the <unpackOverlays> and it works an absolute treat - yay!

          I"ll also try to avoid getRealPath() like the plague - the main reason its so useful is it lets us get access to the lastModified times which is very handy in templating to know if you've gotta reload the generated code etc.

          Show
          james strachan added a comment - I'm so sorry Jan! I'd actually missed your comment on JETTY-1027 - and thought this was a different issue connected to Jetty picking up the wrong file, rather than overlays not working with jetty:run. DOH! Sorry again - dinner on me next time we meet! I've tried the <unpackOverlays> and it works an absolute treat - yay! I"ll also try to avoid getRealPath() like the plague - the main reason its so useful is it lets us get access to the lastModified times which is very handy in templating to know if you've gotta reload the generated code etc.

            People

            • Assignee:
              Jan Bartel
              Reporter:
              james strachan
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: