java - vista - Maven: Personaliza web.xml del proyecto de aplicación web

spring vista

Question

Tengo un proyecto Maven de la aplicación web y quiero personalizar el archivo web.xml en función del perfil que se esté ejecutando. Estoy usando el complemento de Maven-War, que me permite definir un directorio de "recursos", donde se pueden filtrar los archivos. Sin embargo, el filtrado solo no es suficiente para mí.

En más detalle, quiero incluir (o excluir) toda la sección sobre seguridad, en función del perfil que esté ejecutando. Esta es la parte:

....
....
<security-constraint>
<web-resource-collection>
<web-resource-name>protected</web-resource-name>
<url-pattern>/pages/*.xhtml</url-pattern>
<url-pattern>/pages/*.jsp</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>${web.modules.auth.type}</auth-method>
<realm-name>MyRealm</realm-name>
</login-config>
<security-constraint>
....
....

Si esto no se hace fácilmente, ¿hay una manera de tener dos archivos web.xml y seleccionar el apropiado según el perfil?

Answer 1

¿Hay alguna forma de tener dos archivos web.xml y seleccionar el apropiado según el perfil?

Sí, dentro de cada perfil puede agregar una configuración del maven-war-plugin y configurar cada uno para que apunte a un web.xml diferente.

<profiles>
<profile>
<id>profile1</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webXml>/path/to/webXml1</webXml>
</configuration>
</plugin>
...

Como alternativa a tener que especificar la configuración de maven-war-plugin en cada perfil, puede proporcionar una configuración predeterminada en la sección principal de la POM y luego anularla para perfiles específicos.

O para ser aún más simple, en el <build><plugins> de su POM, use una propiedad para referirse al atributo webXml y luego simplemente cambie su valor en diferentes perfiles

<properties>
<webXmlPath>path/to/default/webXml</webXmlPath>
</properties>
<profiles>
<profile>
<id>profile1</id>
<properties>
<webXmlPath>path/to/custom/webXml</webXmlPath>
</properties>
</profile>
</profiles>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webXml>${webXmlPath}</webXml>
</configuration>
</plugin>
...

Answer 2

"matt b" ya ha publicado la respuesta que es la forma más avanzada de hacerlo. Es la forma en que recomendaría hacerlo el 99% del tiempo.

Sin embargo, ocasionalmente, su archivo de configuración puede ser bastante complicado, y no tiene mucho sentido duplicar todo el archivo para cada entorno cuando solo una stanza XML difiere. En estos casos, puede abusar del filtrado de propiedades para lograr su objetivo.

Advertencia, sigue una solución muy duct-tape-y, y no será para los débiles de corazón:

En tu pom.xml:

¡Atención a los editores de !

La entidad html que se escapa es parte de la solución. La solución NO funcionará si lo reemplaza todo con signos mayores y menores. Por favor, deje la respuesta como está ...

<properties>
<test.security.config>
&lt;security-constraint&gt;
&lt;web-resource-collection&gt;
&lt;web-resource-name&gt;protected&lt;/web-resource-name&gt;
&lt;url-pattern&gt;/pages/*.xhtml&lt;/url-pattern&gt;
&lt;url-pattern&gt;/pages/*.jsp&lt;/url-pattern&gt;
&lt;/web-resource-collection&gt;
&lt;auth-constraint&gt;
&lt;role-name&gt;*&lt;/role-name&gt;
&lt;/auth-constraint&gt;
&lt;/security-constraint&gt;
&lt;login-config&gt;
&lt;auth-method&gt;${web.modules.auth.type}&lt;/auth-method&gt;
&lt;realm-name&gt;MyRealm&lt;/realm-name&gt;
&lt;/login-config&gt;
&lt;security-constraint&gt;
</test.security.config>
</properties>

en tu web.xml

....
${test.security.config}
....

Debido a que las propiedades no existentes se evalúan como una cadena vacía, las configuraciones que no tienen esta propiedad establecida (o la propiedad es una etiqueta xml vacía) se evaluarán como una línea en blanco aquí.

Es feo, y el xml es difícil de modificar en esta forma. Sin embargo, si su web.xml es complejo y usted presenta un mayor riesgo de que 4-5 copias del web.xml se desincronicen, este puede ser un enfoque que funcione para usted.

Answer 3

Comenta a Chris Clark la respuesta. Puede revertir, por lo que en el desarrollo no desea tener restricciones (seguridad o jndi, otras)

<!-- ${enable.security.end}
<security-constraint>
...
</security-constraint>
${enable.security.start} -->

Así que en desarrollo has comentado la sección. Pero en producción se traducirá a (con perfil maven):

<!-- -->
<security-constraint>
...
</security-constraint>
<!-- -->

y la sección comentada será visible.

Answer 4

Hay una tercera opción de compromiso que implementé en mi proyecto. Mantiene todo en un web.xml mientras se hace legible tanto a él como a pom.xml. En mi caso, tuve la necesidad de tener seguridad a veces y otras veces no tener seguridad, dependiendo del entorno.

Así que lo que hice fue:

En el archivo pom.xml, defina dos perfiles (o cuantos necesite). Dentro de los perfiles, se incluyen dos propiedades. Cuando quieres seguridad, los dejas vacíos, así:

<enable.security.start></enable.security.start>
<enable.security.end></enable.security.end>

Cuando desee excluir toda la seguridad, defínalos de la siguiente manera:

<enable.security.start>&lt;!--</enable.security.start>
<enable.security.end>--&gt;</enable.security.end>

Entonces, tienes un solo archivo web.xml con lo siguiente:

${enable.security.start}
<security-constraint>
...
// all of the XML that you need, in a completely readable format
...
</login-config>
${enable.security.end}

El plugin maven-war-pom.xml tiene que estar configurado para usar el filtrado. El mío se parece a esto:

 <configuration>
<webResources>
<resource>
<filtering>true</filtering>
<directory>src/main/webapp</directory>
<includes>
<include>**/web.xml</include>
</includes>
</resource>
</webResources>
<warSourceDirectory>src/main/webapp</warSourceDirectory>
<webXml>src/main/webapp/WEB-INF/web.xml</webXml>
...

Entonces, básicamente, cuando selecciona el perfil para incluir seguridad, obtiene dos CRLF adicionales en su web.xml. Cuando selecciona el perfil para NO incluir seguridad, el XML aún está en el web.xml, pero está comentado, por lo que se ignora. Me gusta esto porque no tiene que preocuparse por mantener varios archivos sincronizados, sin embargo, el XML es aún legible (y está en el archivo web.xml donde la gente lo buscaría de forma natural).

Answer 5

Se agregó una nueva configuración a maven-war-plugin en la versión 2.1-alpha-2. Su nombre es filteringDeploymentDescriptors y hace exactamente lo que usted desea.

Esto funciona:

<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<filteringDeploymentDescriptors>true</filteringDeploymentDescriptors>
</configuration>
</plugin>

Y esto también funciona:

<properties>
<maven.war.filteringDeploymentDescriptors>true</maven.war.filteringDeploymentDescriptors>
</properties>

Más información está disponible en la documentación oficial de filteringDeploymentDescriptors .

Answer 6

Una mejora a https://.com/a/3298876/2379360

En lugar de especificar una propiedad personalizada, use la propiedad predeterminada maven.war.webxml en sus diferentes perfiles.

<profiles>
<profile>
<id>profile1</id>
<properties>
<maven.war.webxml>path/to/custom/webXml</webXmlPath>
</properties>
</profile>
</profiles>

Answer 7

is there a way to have two web.xml files and select the appropriate one depending on the profile?

Aparte del enfoque sugerido por matt b, es útil pensar al revés, principalmente porque en muchos casos tendrá que agrupar configuraciones específicas del servidor de aplicaciones que no están cubiertas por los complementos de maven (afaik). Estos pueden muy bien tener diferencias entre los perfiles.

Específicamente, puede usar un proyecto principal que tenga todos los archivos comunes entre proyectos web de diferentes perfiles. Luego, los proyectos secundarios pueden tener diferentes archivos web.xml y el ID de resto realizado con perfiles y el maven-war-plugin . Por ejemplo, he usado este diseño para lograr compilaciones desatendidas (aparte de especificar un perfil) para diferentes entornos de destino (desarrollo, uat, etc.)

WebPc
├── common
│ ├── css
│ ├── images
│ ├── js
│ └── WEB-INF
│ └──├── wsdl
│── pom.xml
│
├── WebPc-DEV
│ ├── pom.xml
│ └── src
│ └── main
│ └── webapp
│ └── WEB-INF
│ ├── geronimo-web.xml
│ ├── ibm-web-bnd.xml
│ ├── ibm-web-ext.xml
│ └── web.xml
├── WebPc-UAT
│ ├── pom.xml
│ └── src
│ └── main
│ └── webapp
│ └── WEB-INF
│ ├── geronimo-web.xml
│ ├── ibm-web-bnd.xml
│ ├── ibm-web-ext.xml
│ └── web.xml

El pom de WebPc tiene el siguiente pom

<groupId>my.grp</groupId>
<artifactId>WebPc</artifactId>
<packaging>pom</packaging>
<profiles>
<profile>
<id>DEV</id>
<activation>
<activeByDefault>true</activeByDefault>
</activation>
<modules>
<module>WebPc-DEV</module>
</modules>
</profile>
<profile>
<id>UAT</id>
<modules>
<module>WebPc-UAT</module>
</modules>
</profile>
</profiles>
<build>
<pluginManagement>
<plugins>
<!-- copy common resources located on parent
project common folder for packaging -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.4</version>
<configuration>
<resourceEncoding>${project.build.sourceEncoding}</resourceEncoding>
<webResources>
<resource>
<directory>../common</directory>
<excludes>
<exclude>WEB-INF/**</exclude>
</excludes>
</resource>
<resource>
<directory>../common/WEB-INF</directory>
<includes>
<include>wsdl/*.wsdl</include>
<include>wsdl/*.xsd</include>
</includes>
<targetPath>WEB-INF</targetPath>
</resource>
</webResources>
</configuration>
</plugin>
</plugins>
</pluginManagement>
</build>

Y este es el pom para WebPc-DEV.

<parent>
<groupId>my.grp</groupId>
<artifactId>WebPc</artifactId>
<version>1.0.0-SNAPSHOT</version>
</parent>
<artifactId>WebPc-DEV</artifactId>
<packaging>war</packaging>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
</plugin>
</plugins>
</build>