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

[Aslak Knutsen (JIRA)]

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

Aslak Knutsen edited comment on SHRINKWRAP-266 at 3/30/11 3:18 AM:
-------------------------------------------------------------------

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.

      was (Author: aslak):
    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.
  
> 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