如何为 Jetty 的 Maven Cargo 插件指定 jetty-env.xml 文件？

Posted 2023-03-30

【中文标题】如何为 Jetty 的 Maven Cargo 插件指定 jetty-env.xml 文件？

【英文标题】：How to specify jetty-env.xml file for Maven Cargo plugin for Jetty?

【发布时间】：2011-05-01 16:17:28

【问题描述】：

我正在从 Maven 的 jetty 插件迁移到 Cargo 插件 (cargo-maven2-plugin)，因为 Cargo 会很高兴地从依赖的 Maven 模块运行 WAR。在 Web 应用程序内部，我们煞费苦心地通过 JNDI 将所有配置外部化。这些 JNDI 定义是特定于 Web 应用程序的，因此放置在 WAR 外部的 jetty-env.xml 文件中。使用 Jetty 插件，我们指定这个文件如下：

        <plugin>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>maven-jetty-plugin</artifactId>
            <configuration>
                <jettyEnvXml>$basedir/target/config/jetty-env.xml</jettyEnvXml>
            </configuration>
        </plugin>

如何在 Cargo 插件中指定这一点？这是我到目前为止的配置。当然，由于缺少 JNDI 配置而失败：

        <plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <configuration>
                    <container>
                        <containerId>jetty6x</containerId>
                        <type>embedded</type>
                    </container>
                    <configuration>
                        <deployables>
                            <deployable>
                                <groupId>com.mycompany</groupId>
                                <artifactId>my-war-module</artifactId>
                                <type>war</type>
                                <properties>
                                   <context>/</context>
                                </properties>
                            </deployable>
                        </deployables>
                    </configuration>
                    <wait>false</wait>
                </configuration>
                <executions>
                           ......
                </executions>
        </plugin>

【参考方案1】：

根据CARGO-804，Cargo 的 Jetty 部署器现在支持在您的战争中嵌入 jetty-env.xml（从 1.0.3 版开始）。

为了将jetty-env.xml 保持在您的“真实”战争之外，我的建议是创建一个额外的战争模块来托管jetty-env.xml 文件并将Cargo 配置为merge WAR files（特别注意<extensions>true</extensions> 重要的元素，如CARGO-524 中所述）。

【讨论】：

看起来我可以将 jetty-env.xml 放在 WEB-INF 目录中，但我不想将 WAR 发送给带有该文件的客户。我希望避免创建另一个 Maven 模块，它的存在只是充当集成测试其他 Maven 模块的服务器。想也许系统属性或命令行参数的某种组合或其他东西可以避免它。

@HDave：是的，我知道您希望将 jetty-env.xml 保留在 WAR 之外，这就是我建议合并方法的原因。但我也明白，可能不希望仅仅为了 Cargo 的目的创建另一个模块。这是我能想到的唯一解决方案。让我们看看你是否找到更好的东西。

@Pascal - 经过一些有限但仔细的研究，我相信您创建另一个 Maven 模块的解决方法是目前唯一可行的方法。我在这里创建了一个增强请求，总结了细节：

@HDave 投票支持并关注问题。也许有人会发布更好的选择......

@Pascal - 使用 zipUrlInstaller 并且它有效。但是请注意，在我将 JTA 1.1 依赖添加到货物中的容器之前，我得到了一个未找到 UserTransaction 类的错误。我真的不知道为什么我必须这样做，但是一旦我通过了那个错误，一切都正常了。

【参考方案2】：

我有同样的问题，并希望进行全新安装。我并没有被 WAR 文件的合并所吸引。相反，我使用程序集来维护所有外部属性的 ZIP 文件。作为一个单独的模块，我可以将 ZIP 文件的内容部署到 JETTY 环境中。反过来，我利用 Jetty 如何使用 Web 应用程序的名称来加载免费的环境文件（对于 webapps/foo.war，Jetty 使用 contexts/foo.xml 进行配置）。因此，虽然它不像纯 Cargo 解决方案那样紧凑，但我更喜欢它，因为 WAR 文件在整个促销过程中的进度是纯正的。该解决方案也是管理所有配置活动的通用机制。如果有人感兴趣，我可以指出更多细节。

【讨论】：

听起来很有趣。我知道 tomcat 会寻找 contexts/foo.xml 但我不知道 Jetty 会。您是说您的解决方案与货物一起工作还是替代货物？能不能把JNDI资源放到foo.xml中？

其实可以，但结果证明这是一个不稳定的选项。它在重新部署时被覆盖。该解决方案与 Cargo 结合使用。我正在与 Jetty 的人讨论这一点，并希望获得一个可靠的解决方案。使用属性看起来很有趣...

嘿，你为我解开了一个谜……所以 Cargo 生成的是配置文件而不是 Jetty！所以是的，你的新答案是理想的。我现在唯一的问题是如何启用属性，以便可以在每个环境中使用相同的 xml 文件...

【参考方案3】：

Mond 的回答引发了一个想法，也许我可以使用 Cargo 的配置将我的（重命名并稍作修改）jetty-env.xml 存放到“contexts”目录中。令我惊讶的是，它刚刚奏效。这是我所做的：

在我的货物配置中，我添加了以下内容：

<configfiles>  
  <configfile>  
      <file>$basedir/../config/jetty-env.xml</file>
    <todir>contexts</todir>
     <tofile>$jetty6.context.xml</tofile>
   </configfile>
</configfiles>

但为了将我的 jetty-env.xml 变成真正的 context.xml，我添加了以下内容：

<!-- Activates the Jetty-Plus feature so we can create/share JNDI resources -->
<Array id="plusConfig" type="java.lang.String">
    <Item>org.mortbay.jetty.webapp.WebInfConfiguration</Item>
    <Item>org.mortbay.jetty.plus.webapp.EnvConfiguration</Item>
    <Item>org.mortbay.jetty.plus.webapp.Configuration</Item>
    <Item>org.mortbay.jetty.webapp.JettyWebXmlConfiguration</Item>
    <Item>org.mortbay.jetty.webapp.TagLibConfiguration</Item>
</Array>

<!-- Miscellaneous properties that were take from the CARGO version of this file that is created automatically
    (and then replaced by this file). If you ever upgrade Cargo you may need to change these. -->
<Set name="contextPath">/$jetty6.context</Set>
<Set name="war">
    <SystemProperty name="config.home" default="."/>/webapps/$jetty6.context.war</Set>
<Set name="extractWAR">true</Set>
<Set name="defaultsDescriptor">
    <SystemProperty name="config.home" default="."/>/etc/webdefault.xml</Set>
<Set name="ConfigurationClasses">
    <Ref id="plusConfig" />
</Set>

我担心 CARGO 在将我的复制到那里后会转储自己的上下文文件，但它足够聪明，最后复制了我的。

【讨论】：

解决方案很酷，但是当我尝试实施时，我面临一些更根本的问题：Cargo 没有生成上下文 xml。如果您能与我分享一些经验，那就太好了。 ***.com/questions/10170949/…

对找到此解决方案的人们的快速说明：此解决方案不适用于嵌入式码头。你需要安装一个。对于自动安装，请参考之前评论中链接中的 HDave 更新。

【参考方案4】：

我想做的其他事情是过滤属性。到目前为止，我有这个：

    <profile>
        <id>deploy-properties</id>
        <activation>
            <activeByDefault>false</activeByDefault>
        </activation>
        <properties>
            <deployable.classifier>properties</deployable.classifier>
            <deployable.type>zip</deployable.type>
            <ys.imq.user>UserFromDeploymentPom</ys.imq.user>
            <ys.imq.password>PasswordFromDeploymentPom</ys.imq.password>
        </properties>
        <dependencies>
            <dependency>
                <groupId>$project.groupId</groupId>
                <artifactId>$deployable.artifactId</artifactId>
                <classifier>$deployable.classifier</classifier>
                <type>$deployable.type</type>
                <version>$project.version</version>
            </dependency>
        </dependencies>
        <build>
            <plugins>
                <plugin>
                    <artifactId>maven-dependency-plugin</artifactId>
                    <executions>
                        <execution>
                            <phase>process-resources</phase>
                            <goals>
                                <goal>unpack</goal>
                            </goals>
                        </execution>
                    </executions>
                    <configuration>
                        <artifactItems>
                            <artifactItem>
                                <groupId>$project.groupId</groupId>
                                <artifactId>$deployable.artifactId</artifactId>
                                <classifier>$deployable.classifier</classifier>
                                <version>$project.version</version>
                                <type>$deployable.type</type>
                                <overWrite>true</overWrite>
                                <outputDirectory>/tmp/$deployable.artifactId</outputDirectory>
                            </artifactItem>
                        </artifactItems>
                    </configuration>
                </plugin>
                <plugin>
                    <artifactId>maven-resources-plugin</artifactId>
                    <version>2.4.3</version>
                    <executions>
                        <execution>
                            <id>copy-resources</id>
                            <phase>package</phase>
                            <goals>
                                <goal>copy-resources</goal>
                            </goals>
                            <configuration>
                                <outputDirectory>$deploy.jettyHome</outputDirectory>
                                <overwrite>true</overwrite>
                                <resources>
                                    <resource>
                                        <directory>/tmp/$deployable.artifactId</directory>
                                        <filtering>true</filtering>
                                    </resource>
                                </resources>
                            </configuration>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
    </profile>

它比我喜欢的要复杂一些，但允许我在将属性添加到 Jetty 的同时过滤属性。这允许使用系统属性覆盖密码和其他机密数据。我们正在使用 Bamboo（我猜 Hudson 类似），并且可以根据环境调整计划。计划可能受到访问控制。这使我们可以在一个地方设置所有部署属性，因此不再有管理员在 Unix 机器上进行黑客攻击。

【讨论】：

这很好，为了降低复杂性，我使用硬编码路径直接从另一个项目模块复制它们。我更喜欢您的方法，因为我的方法破坏了构建可移植性。我相信我们现在已经做到了完美！

仅供参考，我放弃了 JNDI。相反，我决定使用属性。这些可以通过 CLASSPATH 在 Spring 中加载。唯一的技巧是将这些文件添加到 JETTY 中的资源目录中，事实证明，默认情况下该目录位于 CLASSPATH 上。我们还在资源目录下添加了一个目录，并添加了一个带有 extraClassPath 选项的 context.xml 以添加它，以便我们可以在一个 Jetty 实例中支持多个应用程序。