¿Cómo especificar el archivo jetty-env.xml para el plugin Maven Cargo para Jetty?

Question

Estoy migrando desde el plugin de Maven al plugin Cargo (cargo-maven2-plugin) porque Cargo estará feliz de ejecutar WAR de módulos Maven dependientes. Dentro de la aplicación web nos hemos tomado grandes molestias para externalizar toda la configuración a través de JNDI. Estas definiciones JNDI son específicas de la aplicación web y, por lo tanto, se ubican en un archivo jetty-env.xml que está fuera de WAR. Usando el plugin embarcadero, especificamos el archivo de la siguiente manera:

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

¿Cómo hace uno para especificar esto dentro del Plugin Cargo? Esta es la configuración que tengo hasta ahora. Es, por supuesto, en su defecto, debido a la configuración de JNDI ausente:

 <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> 

Answer 1

La respuesta de Mond provocó la idea de que quizás podría usar la configuración de Cargo para depositar mi (rebautizado y ligeramente modificado) embarcadero-env.xml en el directorio "contextos". Para mi sorpresa, simplemente funcionó. Aquí lo que hice:

Para mi configuración de carga que añade lo siguiente:

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

Pero con el fin de convertir mi muelle de una env.xml en un context.xml real que añade lo siguiente:

<!-- 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> 

Estaba preocupado de que CARGO volcara su propio archivo de contexto DESPUÉS de que copiara el mío allí, pero fue lo suficientemente inteligente como para copiar el mío al final.

Answer 2

Según CARGO-804, implementador Muelle de Carga soporta ahora incorporación de un muelle de una env.xml dentro de su guerra (a partir de la versión 1.0.3) .

Y con el fin de mantener el jetty-env.xml fuera de la guerra "real", mi sugerencia sería la creación de un módulo de guerra adicional para alojar el archivo jetty-env.xml y configurar por carretera a merge WAR files (prestar una especial atención al elemento <extensions>true</extensions> lo cual es importante , como se menciona en CARGO-524).

Answer 3

Comparto el mismo problema y deseo tener una instalación limpia. No me atraía la fusión de archivos WAR. En su lugar, utilizo un ensamblaje para mantener un archivo ZIP de todas las propiedades externas. Como módulo separado, puedo implementar los contenidos del archivo ZIP en el entorno JETTY. A su vez, aprovecho cómo Jetty usa el nombre de la aplicación web para cargar un archivo de entorno complementario (para webapps/foo.war Jetty usa contexts/foo.xml para la configuración). Por lo tanto, aunque no es tan compacto como una solución de carga pura, lo prefiero, ya que el archivo WAR no se adultera en su progreso durante todo el proceso de promoción. La solución también es un mecanismo general para administrar todas las actividades de configuración. Puedo señalar más detalles si alguien está interesado.

Answer 4

Otra cosa que quiero hacer es filtrar propiedades. Hasta ahora tengo esto:

<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> 

Es un poco más complicado de lo que me gusta, pero me permite Filtrar mientras que la adición de ellos en Jetty. Esto permite anular las contraseñas y otros datos confidenciales utilizando las propiedades del sistema. Estamos utilizando Bamboo (supongo que Hudson es similar) y uno puede ajustar los planes por entorno. Los planes pueden estar sujetos a control de acceso. Esto nos permite tener un lugar para establecer todas las propiedades de implementación, por lo que no habrá más administradores hackeando en los cuadros de Unix.