[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] Dan Allen commented on SHRINKWRAP-266: -------------------------------------- In essence, the manifest container, as we know it, in a web archive is /WEB-INF/classes/META-INF. Otherwise, the archive is broken. There may be a second manifest container in a web archive, but it serves a completely different purpose and no frameworks (that I know of) recognize it. The only case I've ever seen for /META-INF/ in a web archive is for Tomcat's context.xml, and even that floats into WEB-INF depending on the deployment environment. /META-INF/ of a web archive is an edge case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] Aslak Knutsen commented on SHRINKWRAP-266: ------------------------------------------ A WebArchive is a composit Archive type which does not really match our idea of Containers, or more, it matches multiple of the same container types at once. |/|Special to WebArchive, (a root that is not part of Classpath?)| |/WEB-INF/|Special to WebArchive| |/WEB-INF/classes/*|A exploded JavaArchive| |/WEB-INF/lib/*|Multiple packed JavaArchives| |/META-INF/*|Standard ManifestContainer for MANIFEST.FM but nothing more?| Our current model does not support the idea of a whole ArchiveType as a nested Container. It could look a bit more like this (i'm sure we can make it less clunky with some thought): {code} public interface WebArchive extends ManifestContainer, // /META-INF LibraryContainer, // /WEB-INF/lib WebContainer, // / SingleNestedContainer<JavaArchive> // /WEB-INF/classes {} public interface SingleNestedContainer<T> { T nested() } ShrinkWrap.create(WebArchive.class) .addAsWebResource("my.jsp") // / .nested() .addClasses() // /WEB-INF/classes .addAsServiceProvider() // /WEB-INF/classes/META-INF {code} Not loving the extract level(or the names), but it does model how it works. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-266: -------------------------------------------- History of the decision to not do a straight "WEB-INF/classes/META-INF" as the manifest location: WEB-INF/classes/META-INF was deemed to be an anomaly introduced by the persistence spec. 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. For example, an application for issue tracking might be distributed in an archive file called issuetrack.war. When packaged into such a form, a META-INF directory will be present which contains information useful to Java archive tools. This directory must not be directly served as content by the container in response to a Web client’s request, though its contents are visible to servlet code via the getResource and getResourceAsStream calls on the ServletContext. Also, any requests to access the resources in META-INF directory must be returned with a SC_NOT_FOUND(404) response." Another reference, 10.7.1, use of extension-list, which is a JAR standard described META-INF/MANIFEST.MF: "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. The format of the manifest entry should follow standard JAR manifest format." Yet another reference: "A single file that contains all of the components of a web application. This archive file is created by using standard JAR tools which allow any or all of the web components to be signed." (in the glossary) Signed is referring to jar signing. The standard tool for signing, jarsigner looks in META-INF/MANIFEST.MF And there is also EE 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" -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] Dan Allen edited comment on SHRINKWRAP-266 at 3/30/11 12:48 PM: ---------------------------------------------------------------- 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 framework configs (as migrated from src/main/resources/META-INF). 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 leaves the service provider registration broken, 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. was (Author: dan.j.allen): 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 framework configs (as migrated from src/main/resources/META-INF). 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] Dan Allen commented on SHRINKWRAP-266: -------------------------------------- The more I look into this, my proposal is accurate to how other packaging tools organize files. war.addAsManifestResource() -> /WEB-INF/classes/META-INF/ war.addAsServiceProvider() -> /WEB-INF/classes/META-INF/services/ war.setManifest() -> /META-INF/MANIFEST.MF -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] Andrew Rubinger commented on SHRINKWRAP-266: -------------------------------------------- I still think "addAsManifestResource" for Web Containers should *not* point to /WEB-INF/classes/META-INF. From the spec references cited above, it's clear that the "manifest" location is simply "META-INF". Recommend finding some other name for this. Especially since this anomaly is being discussed by the EG. Tommy, open a forum Thread and we'll get other EE EG guys to weigh in? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] Tommy Tynjä commented on SHRINKWRAP-266: ---------------------------------------- Added forum discussion reference to issue: http://community.jboss.org/thread/165436. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] Tommy Tynjä commented on SHRINKWRAP-266: ---------------------------------------- I've pushed a proposal which overrides the addAsServiceProvider method in WebContainerBase to add service providers in WEB-INF/classes/META-INF/services instead: https://github.com/tommysdk/shrinkwrap/commit/dadd7297390732e0d12585f7d66... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/SHRINKWRAP-266?page=com.atlassian.jira.pl... ] Andrew Rubinger resolved SHRINKWRAP-266. ---------------------------------------- Fix Version/s: 1.0.0-beta-3 Resolution: Done Upstream: https://github.com/shrinkwrap/shrinkwrap/commit/cf1978be1ab078781108e9200... https://github.com/shrinkwrap/shrinkwrap/commit/cf1978be1ab078781108e9200... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira