jira-importer opened a new issue, #134:
URL: https://github.com/apache/maven-war-plugin/issues/134

   **[Richard W. Eggert 
II](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=reggert)** 
opened 
**[MWAR-307](https://issues.apache.org/jira/browse/MWAR-307?redirect=false)** 
and commented
   
   The containerConfigXML configuration parameter allows the user to specify a 
container-specific deployment descriptor file (context.xml, jboss-web.xml, 
jetty-web.xml, sun-web.xml, weblogic.xml, etc.) to include in the WAR. The 
plugin places this file in the WAR file's META-INF directory.
   
   However, expecting the file in this location is behavior unique to Tomcat. 
Every other webapp container in the universe (and possibly parallel universes - 
I can't be too sure) expects the container-specific deployment descriptor to be 
located in WEB-INF (alongside web.xml), though some containers are flexible in 
this regard.
   
   The current plugin behavior makes this configuration parameter unusable when 
packaging for any container other than Tomcat, forcing users to configure the 
file as a "webResource" instead.
   
   The location within the WAR where the container-specific deployment 
descriptor is placed ought to be configurable. I would even say that WEB-INF 
should be the default, since that is where every container except Tomcat 
expects it to be (and is where it logically should be, since that is where 
web.xml goes), but that would unfortunately break it for projects that already 
rely on the current behavior.
   
   
   ---
   
   **Affects:** 2.4
   
   **Issue Links:**
   - [MWAR-213](https://issues.apache.org/jira/browse/MWAR-213) Rename 
containerConfigXML if it does not match context.xml
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to