使用 uberwar 合并 WAR 的问题(cargo-maven2-plugin)
我刚刚开始使用 Cargo-maven2-plugin 在构建过程中合并 WAR 工件,并且遇到了 uberwar mojo 的问题。 合并工作正常,但生成的 web.xml 文件包含额外的“xmlns”属性,这些属性在 Jboss 上部署时会导致错误。
例如,原始 context-param 元素如下所示:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/config/web-application-config.xml</param-value>
</context-param>
合并后它具有额外的“xmlns”属性:
<context-param xmlns="">
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/config/web-application-config.xml</param-value>
</context-param>
我发现了以下 Jira 问题,但建议的解决方案对我来说不清楚: http://jira.codehaus.org/browse/CARGO-639
任何人都遇到过类似的问题并可以分享解决方案吗? 如果您使用其他(有效的)工具来合并 WAR,请告诉我。
我的配置是: Mac OS X
Java 1.6
Maven 2.1
Cargo-maven2-plugin 1.1.0-SNAPSHOT
Servlet 规范 2.5 (web.xml)
I've just started using cargo-maven2-plugin to merge WAR artifacts during build process and I encountered problem with uberwar mojo.
Merging works fine but resulting web.xml file contains extra "xmlns" attributes that cause error when deploying on Jboss.
For example original context-param element looks like this:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/config/web-application-config.xml</param-value>
</context-param>
and after merging it has extra "xmlns" attribute:
<context-param xmlns="">
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/config/web-application-config.xml</param-value>
</context-param>
I have found the following Jira issue but suggested solution is not clear to me:
http://jira.codehaus.org/browse/CARGO-639
Anybody faced similar problem and could share the solution?
If you use other tools (that work) to merge WARs please let me know.
My configuration is:
Mac OS X
Java 1.6
Maven 2.1
cargo-maven2-plugin 1.1.0-SNAPSHOT
Servlets spec 2.5 (web.xml)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我们在使用
cargo uberwar
功能时遇到了问题,因为我们不仅有通用的 xml 文件,还有属性文件。我们使用战争覆盖。我们确保主 war 文件具有我们在应用程序中所需的配置的超集。
We had issues using
cargo uberwar
feature since we not only had common xml files, but also property files.We overcame the issue (albeit in an ugly way) using war overlay. We ensured that the master war file had the superset of configurations that we wanted in the application.