5:08 p.m.
remap targets for WebArchive add methods
----------------------------------------
Key: SHRINKWRAP-241
URL: https://jira.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:08 p.m.
New subject: [JBoss JIRA] Updated: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://jira.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.plug...
]
Dan Allen updated SHRINKWRAP-241:
---------------------------------
Summary: remap targets for WebArchive add* methods (was: remap targets for WebArchive
add methods)
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://jira.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:13 p.m.
New subject: [JBoss JIRA] Updated: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://jira.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.plug...
]
Andrew Rubinger updated SHRINKWRAP-241:
---------------------------------------
Priority: Blocker (was: Major)
Will block the Beta releases; may be bumped only within Alpha.
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://jira.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:46 p.m.
New subject: [JBoss JIRA] Assigned: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Andrew Rubinger reassigned SHRINKWRAP-241:
------------------------------------------
Assignee: Andrew Rubinger
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:41 a.m.
New subject: [JBoss JIRA] Commented: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKWRAP-241:
--------------------------------------------
Started up: https://github.com/ALRubinger/shrinkwrap/tree/SHRINKWRAP-241
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:23 a.m.
New subject: [JBoss JIRA] Commented: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKWRAP-241:
--------------------------------------------
What about "addAsManifestResource"? Does this go away? Is a WebArchive still a
ManifestContainer?
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:40 a.m.
New subject: [JBoss JIRA] Commented: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Aslak Knutsen commented on SHRINKWRAP-241:
------------------------------------------
WEB-INF/classes/META-INF i think is valid for persistence.xml
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:17 p.m.
New subject: [JBoss JIRA] Commented: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKWRAP-241:
--------------------------------------------
OK, so we'll keep WebArchive as a ManifestContainer, with the following mappings:
addAsWebInfResource() - /WEB-INF
addAsWebResource() - /
addAsResource() /WEB-INF/classes
addAsManifestResource() - /WEB-INF/classes/META-INF
add() - /
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:54 a.m.
New subject: [JBoss JIRA] Commented: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Aslak Knutsen commented on SHRINKWRAP-241:
------------------------------------------
looks right
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:07 a.m.
New subject: [JBoss JIRA] Commented: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Andrew Rubinger commented on SHRINKWRAP-241:
--------------------------------------------
Pushed to upstream/master. Aslak and Dan can review this before we resolve.
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:50 a.m.
New subject: [JBoss JIRA] Resolved: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Andrew Rubinger resolved SHRINKWRAP-241.
----------------------------------------
Resolution: Done
With no complaints, resolving.
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:09 a.m.
New subject: [JBoss JIRA] Reopened: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Andrew Rubinger reopened SHRINKWRAP-241:
----------------------------------------
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"
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:24 p.m.
New subject: [JBoss JIRA] Resolved: (SHRINKWRAP-241) remap targets for WebArchive add* methods
[
https://issues.jboss.org/browse/SHRINKWRAP-241?page=com.atlassian.jira.pl...
]
Andrew Rubinger resolved SHRINKWRAP-241.
----------------------------------------
Resolution: Done
New location mappings:
addAsWebInfResource() - /WEB-INF
addAsWebResource() - /
addAsResource() /WEB-INF/classes
addAsManifestResource() - /META-INF
add() - /
remap targets for WebArchive add* methods
-----------------------------------------
Key: SHRINKWRAP-241
URL: https://issues.jboss.org/browse/SHRINKWRAP-241
Project: ShrinkWrap
Issue Type: Feature Request
Components: api
Affects Versions: 1.0.0-alpha-11
Reporter: Dan Allen
Assignee: Andrew Rubinger
Priority: Blocker
Fix For: 1.0.0-alpha-12
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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4844
days inactive
4944
days old
shrinkwrap-issues@lists.jboss.org
12 comments
3 participants
participants (3)
-
Andrew Rubinger (JIRA) -
Aslak Knutsen (JIRA)
-
Dan Allen (JIRA)