Uploaded image for project: 'ShrinkWrap'
  1. ShrinkWrap
  2. SHRINKWRAP-241

remap targets for WebArchive add* methods

    Details

    • Type: Feature Request
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Done
    • Affects Version/s: 1.0.0-alpha-11
    • Fix Version/s: 1.0.0-alpha-12
    • Component/s: api
    • Labels:
      None
    • Affects:
      Compatibility/Configuration
    • Estimated Difficulty:
      Low
    • Similar Issues:
      Show 10 results 

      Description

      The Servlet specification specifically defines static and dynamic served from the web application as "web resources". Hence, the use of "addWebResource" to refer to WEB-INF is a mistake, and reopens the discussion of how each add* method should be mapped.

      Currently, the targets for the WebArchive add methods are:

      add() maps to /
      addResource() maps to /
      addWebResource() maps to /WEB-INF
      addManifestResource() maps to /WEB-INF/classes/META-INF

      (I know these are being refactor to "addAs". I'm just sticking with the terminology that's currently in place for the purpose of this discussion).

      To start, I think we should explicitly refer to WEB-INF by name, as in:

      addWebInfResource() maps to /WEB-INF

      Next, we should honor the "web resource" definition from the Servlet specification

      addWebResource() maps to /

      Now, because WebArchive is inheriting addResource() from ResourceArchive, we should honor the function of the target location, so:

      addResource() maps to /WEB-INF/classes

      Finally, we have to address add() inherited from Archive. In this case, I'm okay with sticking with add() as meaning the root of whatever archive we have:

      add() maps to /

      So, here's what an example might look like:

      WebArchive war = ShrinkWrap.create(WebArchive.class, "app.war")
      .addWebInfResource(EmptyAsset.INSTANCE, "beans.xml")
      .addWebResource(new StringAsset("<html><body>Hello World!</body></html>"), "index.html")
      .addResource(new StringAsset("foo=bar"), "messages.properties);
      System.out.println(war.toString(true));

      prints:

      app.war
      /index.html
      /WEB-INF/beans.xml
      /WEB-INF/classes/messages.properties

      To me, this makes so much more sense. Hopefully you share the same opinion.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            aslak Aslak Knutsen added a comment -

            looks right

            Show
            aslak Aslak Knutsen added a comment - looks right
            Hide
            alrubinger Andrew Rubinger added a comment -

            Pushed to upstream/master. Aslak and Dan can review this before we resolve.

            Show
            alrubinger Andrew Rubinger added a comment - Pushed to upstream/master. Aslak and Dan can review this before we resolve.
            Hide
            alrubinger Andrew Rubinger added a comment -

            With no complaints, resolving.

            Show
            alrubinger Andrew Rubinger added a comment - With no complaints, resolving.
            Hide
            alrubinger Andrew Rubinger added a comment -

            Reopening.

            While persistence.xml does go into WEB-INF/classes/META-INF, this does not infer that the manifest location of a WAR changes.

            Servlet 3.0 10.6:

            "Web applications can be packaged and signed into a Web ARchive format (WAR) file using the standard Java archive tools. ...When packaged into such a form, a META-INF directory will be present which contains information useful to Java
            archive tools.

            Servlet 3.0 10.7.1:

            "The application developer depending on such an extension or extensions must provide a META-INF/MANIFEST.MF entry in the WAR file listing all extensions needed by the WAR."

            Java EE 6 8.2.1:

            "A JAR format file (such as a .jar file, .war file, or .rar file) may reference a .jar file or directory by naming the referenced .jar file or directory in a Class-Path header in the referencing JAR file’s Manifest file. The referenced .jar file or directory is named using a URL relative to the URL of the refer- encing JAR file. The Manifest file is
            named META-INF/MANIFEST.MF in the JAR file. The Class-Path entry in the Manifest file is of the form"

            Show
            alrubinger Andrew Rubinger added a comment - Reopening. While persistence.xml does go into WEB-INF/classes/META-INF, this does not infer that the manifest location of a WAR changes. Servlet 3.0 10.6: "Web applications can be packaged and signed into a Web ARchive format (WAR) file using the standard Java archive tools. ...When packaged into such a form, a META-INF directory will be present which contains information useful to Java archive tools. Servlet 3.0 10.7.1: "The application developer depending on such an extension or extensions must provide a META-INF/MANIFEST.MF entry in the WAR file listing all extensions needed by the WAR." Java EE 6 8.2.1: "A JAR format file (such as a .jar file, .war file, or .rar file) may reference a .jar file or directory by naming the referenced .jar file or directory in a Class-Path header in the referencing JAR file’s Manifest file. The referenced .jar file or directory is named using a URL relative to the URL of the refer- encing JAR file. The Manifest file is named META-INF/MANIFEST.MF in the JAR file. The Class-Path entry in the Manifest file is of the form"
            Hide
            alrubinger Andrew Rubinger added a comment -

            New location mappings:

            addAsWebInfResource() - /WEB-INF
            addAsWebResource() - /
            addAsResource() /WEB-INF/classes
            addAsManifestResource() - /META-INF
            add() - /

            Show
            alrubinger Andrew Rubinger added a comment - New location mappings: addAsWebInfResource() - /WEB-INF addAsWebResource() - / addAsResource() /WEB-INF/classes addAsManifestResource() - /META-INF add() - /

              People

              • Assignee:
                alrubinger Andrew Rubinger
                Reporter:
                dan.j.allen Dan Allen
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development