Acceder a Properties Según el Contexto con Spring y Tomcat

Cuando una aplicación web se instala en diferentes servidores suele ser necesario modificar ciertos parámetros como direcciones de otros servidores (por ejemplo de correo), parámetros de conexión a la base de datos o hasta parámetros internos de la aplicación como cantidad de usuarios admitidos o nivel de log.

En un clarísimo artículo intitulado 6 Tips for Managing Property Files with Spring ese es uno de los temas: tener diferentes valores para ciertas properties según en qué ambiente o contexto está ejecutándose la aplicación. Una de las posibles soluciones es tener varios archivos llamados por ejemplo

  • database-prod.properties
  • database-test.properties
  • database-desa.properties

Cada archivo tendrá las mismas properties con los valores acordes a cada ambiente (producción, desarrollo y testing en el ejemplo). Lo que tenemos que hacer es que se lea el archivo correcto según el ambiente.

La clave es Spring que tiene un mecanismo muy flexible para acceder a properties mediante el PropertyPlaceholderConfigurer o el PropertySourcesPlaceholderConfigurer. Esos beans hacen el trabajo pesado; nosotros sólo tenemos que configurarlos según nuestras necesidades.

Una configuración típica de ese bean es algo así

 <context:property-placeholder
        location="classpath:database.properties"
        system-properties-mode="OVERRIDE"
        ignore-unresolvable="true"/>

Teniendo muchas versiones del archivo database.properties, la configuración quedaría de esta forma

 <context:property-placeholder
        location="classpath:database-${ambiente}.properties"
        system-properties-mode="OVERRIDE"
        ignore-unresolvable="true"/>

La intención es que ${ambiente} se reemplace por “desa”, “test” o “prod”. Para lograrlo hay que hacer estos pasos:

1) Definir en el archivo server.xml del Tomcat una variable de entorno dentro de GlobalNamingResources

  <Environment
            name="ambiente"
            value="desa"
            type="java.lang.String"
            override="false"/>

2) Definir en el elemento Context en el archivo META-INF/context.xml de la aplicación web esta referencia a la variable que creamos en el punto anterior

  <ResourceLink
      global="ambiente"
      name="ambiente"
      type="java.lang.String"/>

De esa forma Spring va a leer el archivo properties según el valor definido en el server.xml.

Programar en C con Garbage Collection

De los 20 lenguajes mejor ubicados en el índice TIOBE, 14 tienen alguna forma de “Garbage Collection“. Esos 14 lenguajes representan más de un 47% de peso en el índice. Los únicos lenguajes “importantes” que no tienen recolección automática de basura son C, C++ y Objective-C (Delphi, Pascal y Ada son minoritarios).

El caso de Objective-C es especial ya que desde la versión 2.0 tiene un garbage collector, pero es opcional y no está en la versión que se usa para desarrollar aplicaciones para el iPhone.

En C y C++ se puede usar el garbage collector de Boehm-Demers-Weiser. Básicamente en lugar de llamar a malloc, llamas a GC_MALLOC y los llamados a GC_FREE son opcionales.

En Ubuntu, debemos instalar libgc

 sudo apt-get install libgc-dev libgc1c2

y al compilar debemos usar la opción -lgc para indicarle al linker que use libgc.

gcc -std=c99 -Wall  -o programa *.c -lgc