Details
-
Feature Request
-
Resolution: Done
-
Blocker
-
1.0.0-alpha-11
-
None
-
Compatibility/Configuration
-
Low
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.
Attachments
Issue Links
- is related to
-
SHRINKWRAP-172 Clean up API
-
- Closed
-
-
-
- Closed
-
