[
https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl...
]
Dan Allen commented on SHRINKWRAP-266:
--------------------------------------
ALR, I agree that we are dealing with an inconsistency. I think it's important to
recognize that we have two situations to address:
1. how to map addAsManifestResource, perhaps by addressing/acknowledging in the API that
there are two manifests for a web archive
2. fixing the behavior that was broken when the target changed; namely,
addAsServiceProvider on WebArchive is currently *broken*
Perhaps with #2, we have unnecessary coupling. addAsServiceProvider shouldn't target
the manifest location, it should target the location where it belongs per archive, which
is WEB-INF/classes/META-INF in the case of a WebArchive
Aslak's original idea may still fit here. Perhaps WebArchive needs to expose access to
the internal exploded JAR structure:
{code:java}
WebArchive war = ShrinkWrap.create(WebArchive.class, "test.war")
.classpath()
.addAsManifestResource("persistence.xml")
.addClass(FooBar.class)
.addAsServiceProvider(Extension.class, MyExtension.class)
.webroot()
.addAsManifestResource("foo.properties");
{code}
produces:
/META-INF
/META-INF/foo.propeties
/WEB-INF
/WEB-INF/classes
/WEB-INF/classes/FooBar.class
/WEB-INF/classes/META-INF
/WEB-INF/classes/META-INF/javax.enterprise.inject.spi.Extension
/WEB-INF/classes/META-INF/persistence.xml
classpath() could be an alias to as(JavaArchive.class) and webroot() and alias to
as(WebArchive.class).
The other option is to fix the broken behavior (service providers must go in
WEB-INF/classes/META-INF in a WebArchive), then just add a method for putting arbitrary
resources in that location:
.addAsClassesManifestResource("persistence.xml")
I can live with either. What's most important to me is that we aren't creating
broken archives.
Manifest container for WebArchive should be WEB-INF/classes/META-INF
--------------------------------------------------------------------
Key: SHRINKWRAP-266
URL:
https://issues.jboss.org/browse/SHRINKWRAP-266
Project: ShrinkWrap
Issue Type: Bug
Components: impl-base
Affects Versions: 1.0.0-alpha-12
Reporter: Dan Allen
This issue is a regression of SHRINKWRAP-186. The location of the ManifestContainer for a
WebArchive should be /WEB-INF/classes/META-INF, not /META-INF. This location is backed up
by our target locations per archive type page.
http://community.jboss.org/wiki/Containerrootsperspecarchive
A sample use case is bundling a persistence.xml in a web archive:
{code:java}
WebArchive war = ShrinkWrap.create(WebArchive.class, "test.war")
.addAsManifestResource("test-persistence.xml",
"persistence.xml");
System.out.println(war.toString(true));
{code}
Current output:
{code}
test.war
/META-INF/
/META-INF/persistence.xml
{code}
Expected output:
{code}
test.war
/WEB-INF/
/WEB-INF/classes/
/WEB-INF/classes/persistence.xml
{code}
This also breaks the ServiceLoader registrations, as they appear in /META-INF/services/
rather than in /WEB-INF/classes/META-INF/services/
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira