[shrinkwrap-issues] [JBoss JIRA] Commented: (SHRINKWRAP-266) Manifest container for WebArchive should be WEB-INF/classes/META-INF

Dan Allen (JIRA) jira-events at lists.jboss.org
Wed Mar 30 12:47:37 EDT 2011


    [ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592769#comment-12592769 ] 

Dan Allen commented on SHRINKWRAP-266:
--------------------------------------

It's clear the Servlet spec is attempting to serve two masters. But WEB-INF/classes/META-INF is certainly not an anomaly introduced by the persistence specification. Inside the web archive, the location of the resource "META-INF" is "WEB-INF/classes/META-INF". Many other things go here, including shared JSF resources, service provider descriptors, beans.xml (alt location), and other frameworks. Really the only thing that goes in the root META-INF is MANIFEST.MF. So perhaps setManifest() is our special case.

I don't like the nesting either. It makes the API too complex. Though if you did choose it, I would suggest classpath() rather than nested(). But I'm not in favor of the concept in general.

bq. webArchive.addAsWebInfClassesMetaInf(something); // Teehee on the name, but you get the idea

The problem with doing this is that it still breaks the service provider registration, which is really the bigger concern for me. 

How about this proposal?

war.addAsManifestResource() -> /WEB-INF/classes/META-INF/
war.addAsServiceProvider() -> /WEB-INF/classes/META-INF/services/
war.setManifest() -> /META-INF/MANIFEST.MF

That's more reflective of how things really are.

Plus, it fits the user's expectations much better, since:

war.addAsResource() -> /WEB-INF/classes

And I still say, that if you must have a way to add arbitrary resources to /META-INF at the root of the web archive, then you either do:

war.addWebResource("myfile", "META-INF/myfile") -> /META-INF/myfile

or you offer:

war.addAsWebManifestResource("myfile") -> /META-INF/myfile

I think we need to cater to the path of most common usage and not get stuck in particulars.

> 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


More information about the shrinkwrap-issues mailing list