Jetty
  1. Jetty
  2. JETTY-1027

mvn jetty:run does not seem to support WAR overlays...

    Details

    • Type: Improvement Improvement
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.0.2
    • Component/s: Maven
    • Labels:
      None
    • Number of attachments :
      0

      Description

      one neat feature in the WAR plugin is overlays

      http://maven.apache.org/plugins/maven-war-plugin/overlays.html

      so you can share some code/content across WARs.

      Though it looks like "jetty:run" does not support them (though jetty:run-war does)

        Issue Links

          Activity

          Hide
          james strachan added a comment -

          could it be that jetty:run uses a different class loader - where if some resources is in the local project and also in an overlay war, it barfs (so it looks like the resource does not exist?)

          I can point you at an example project shortly which has this issue; "mvn jetty:run" fails, but "mvn jetty:run-war" works...

          Show
          james strachan added a comment - could it be that jetty:run uses a different class loader - where if some resources is in the local project and also in an overlay war, it barfs (so it looks like the resource does not exist?) I can point you at an example project shortly which has this issue; "mvn jetty:run" fails, but "mvn jetty:run-war" works...
          Hide
          David Yu added a comment -
          Show
          David Yu added a comment - See http://docs.codehaus.org/display/JETTY/Multiple+WebApp+Source+Directory the ordering is trivial.
          Hide
          David Yu added a comment -

          JETTY-1028 is fixed for 6.1.19 .. w/c could be related.
          You can verify that the overlays work by doing a jetty:run on contrib/cometd/demo

          Please re-open if you have a test-case where jetty:run does not handle the overlays.

          Show
          David Yu added a comment - JETTY-1028 is fixed for 6.1.19 .. w/c could be related. You can verify that the overlays work by doing a jetty:run on contrib/cometd/demo Please re-open if you have a test-case where jetty:run does not handle the overlays.
          Hide
          james strachan added a comment -

          thanks for the feedback. Any idea when 6.1.19 is out? I'll give this another test as soon as I get a chance!

          Show
          james strachan added a comment - thanks for the feedback. Any idea when 6.1.19 is out? I'll give this another test as soon as I get a chance!
          Hide
          David Yu added a comment -

          I'm not sure but It would probably be before the 1st half of july.

          Show
          David Yu added a comment - I'm not sure but It would probably be before the 1st half of july.
          Hide
          james strachan added a comment -

          I'm wondering if the failure is in calls to

          servletContext.getRealPath(uri)
          

          any idea if the contrib/cometd/demo uses that API?

          Show
          james strachan added a comment - I'm wondering if the failure is in calls to servletContext.getRealPath(uri) any idea if the contrib/cometd/demo uses that API?
          Hide
          Jan Bartel added a comment -

          James,

          No, the cometd demo doesn't call getRealPath. Have you got a project that produces the error?

          cheers
          Jan

          Show
          Jan Bartel added a comment - James, No, the cometd demo doesn't call getRealPath. Have you got a project that produces the error? cheers Jan
          Hide
          james strachan added a comment -

          I do - though its a refactor to use maven overlays that caused me to hit this issue again and didn't wanna check in my changes as it breaks everything . When I've got it working later today (I hope) I'll post you details of the sample application.

          On further debugging (after switching to 7.0.1.v20091125 of the plugin) - it seems that the issue is actually calling servletContext.getRealPath(uri) for a resource which is not within WEB-INF. It works perfectly for stuff inside WEB-INF! I think this might be due to the plugin making target/webinf and target/jsp and my resources are not JSP files and were not in WEB-INF.

          So for now my work around is to put all resources I want to reuse from the overlays and access via servletContext.getRealPath(uri) inside WEB-INF.

          Show
          james strachan added a comment - I do - though its a refactor to use maven overlays that caused me to hit this issue again and didn't wanna check in my changes as it breaks everything . When I've got it working later today (I hope) I'll post you details of the sample application. On further debugging (after switching to 7.0.1.v20091125 of the plugin) - it seems that the issue is actually calling servletContext.getRealPath(uri) for a resource which is not within WEB-INF. It works perfectly for stuff inside WEB-INF! I think this might be due to the plugin making target/webinf and target/jsp and my resources are not JSP files and were not in WEB-INF. So for now my work around is to put all resources I want to reuse from the overlays and access via servletContext.getRealPath(uri) inside WEB-INF.
          Hide
          james strachan added a comment -

          for completeness here's the project...

          http://github.com/scalate/scalate

          the sub-module which reuses a maven war overlay is the scalate-sample (which reuses the scalate-war WAR)...

          http://github.com/scalate/scalate/tree/master/scalate-sample/

          to get things to work I had to move all the resources I wanted to share inside WEB-INF - which is now working perfectly! Huge thanks for all your help. Jetty rocks!

          Show
          james strachan added a comment - for completeness here's the project... http://github.com/scalate/scalate the sub-module which reuses a maven war overlay is the scalate-sample (which reuses the scalate-war WAR)... http://github.com/scalate/scalate/tree/master/scalate-sample/ to get things to work I had to move all the resources I wanted to share inside WEB-INF - which is now working perfectly! Huge thanks for all your help. Jetty rocks!
          Hide
          Jan Bartel added a comment -

          Hi James,

          So the problem is that you're trying to get the path of a resource out of a packed war.

          Here's the javadoc from the getRealPath method:

          • Returns a <code>String</code> containing the real path
          • for a given virtual path. For example, the path "/index.html"
          • returns the absolute file path on the server's filesystem would be
          • served by a request for "http://host/contextPath/index.html",
          • where contextPath is the context path of this ServletContext..
            *
          • <p>The real path returned will be in a form
          • appropriate to the computer and operating system on
          • which the servlet container is running, including the
          • proper path separators. This method returns <code>null</code>
          • if the servlet container cannot translate the virtual path
          • to a real path for any reason (such as when the content is
          • being made available from a <code>.war</code> archive).

          So when you're running with an overlayed war, we can pull out a stream to the resource to serve them back to you, but we can't return you the path on disk because its inside the war.

          An immediate workaround would be to not do jetty:run but jetty:run-war, so the overlay plugin processes the the wars and merges them together.

          Perhaps we should add an option so the mvn jetty:run plugin was to take all the dependent overlayed wars and unpacks them before deploying the target webapp.

          cheers
          Jan

          Show
          Jan Bartel added a comment - Hi James, So the problem is that you're trying to get the path of a resource out of a packed war. Here's the javadoc from the getRealPath method: Returns a <code>String</code> containing the real path for a given virtual path. For example, the path "/index.html" returns the absolute file path on the server's filesystem would be served by a request for "http://host/contextPath/index.html", where contextPath is the context path of this ServletContext.. * <p>The real path returned will be in a form appropriate to the computer and operating system on which the servlet container is running, including the proper path separators. This method returns <code>null</code> if the servlet container cannot translate the virtual path to a real path for any reason (such as when the content is being made available from a <code>.war</code> archive). So when you're running with an overlayed war, we can pull out a stream to the resource to serve them back to you, but we can't return you the path on disk because its inside the war. An immediate workaround would be to not do jetty:run but jetty:run-war, so the overlay plugin processes the the wars and merges them together. Perhaps we should add an option so the mvn jetty:run plugin was to take all the dependent overlayed wars and unpacks them before deploying the target webapp. cheers Jan
          Hide
          Jan Bartel added a comment -

          Reopening with fix.

          Show
          Jan Bartel added a comment - Reopening with fix.
          Hide
          Jan Bartel added a comment -

          James,

          I've committed a fix to jetty-7 codehaus trunk.

          If you put this configuration into your jetty-maven-plugin pom:

          <webAppConfig>
          <unpackOverlays>true</unpackOverlays>

          then all the overlayed wars will be unpacked to the target/tmp directory and thus ServletContext.getRealPath() will return a good value.

          This fix will go into jetty-maven-plugin 7.0.2, due out next week, so stay tuned.

          cheers
          Jan

          Show
          Jan Bartel added a comment - James, I've committed a fix to jetty-7 codehaus trunk. If you put this configuration into your jetty-maven-plugin pom: <webAppConfig> <unpackOverlays>true</unpackOverlays> then all the overlayed wars will be unpacked to the target/tmp directory and thus ServletContext.getRealPath() will return a good value. This fix will go into jetty-maven-plugin 7.0.2, due out next week, so stay tuned. cheers Jan

            People

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

              Dates

              • Created:
                Updated:
                Resolved: