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 -

          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: