Map.computeIfAbsent()

Logo de Java

Aunque está ya desde Java 8, acabo de descubrir el método computeIfAbsent() de Map

Hay veces que en mi código tengo un Map cuya clave es cualquier cosa, un String por ejemplo, y que el valor es a su vez otra Collection, por ejemplo, una List

Map<String, List<Integer>> myMap = new HashMap<>();

Cuando llegaba el momento de meter un nuevo Integer en la lista valor, siempre había que comprobar primero si había o no lista para crearla en caso de que no. Luego ya se podía añadir el Integer

if (null == myMap.get("key1")) {
   myMap.put("key1", new ArrayList());
}
myMap.get("key1").put(anInteger);

Pues bien, el método computeIfAbsent() nos facilita esta tarea. El código quedaría

myMap.computeIfAbsent("key1", k->new ArrayList()).add(anInteger);

Básicamente, si el valor de «key1» existe, devuelve el valor List que corresponda. Si no existe, llama a lo de new ArrayList(), lo mete en el Map y lo devuelve

En cualquiera de los dos casos, devuelve la List. Ya solo nos queda llamar al método add() del List devuelto para meter el entero.

Una de las ventajas de tener en el IDE un analizador estático de código, estilo SonarLint y fijarse en las sugerencias que te hace.

Publicado en java | Etiquetado | Deja un comentario

Proguard con Maven y con Gradle

Una asignatura pendiente que tengo es ofuscar el código con Proguard. Dos «requisitos»

  • Que se haga automáticamente durante el proceso de desarrollo. Cada vez que compile y genere jars, que se generen los ofuscados.
  • Y con el requisito anterior, que mi entorno de desarrollo use los jar ofuscados directamente. De esta forma, sobre mi entorno de desarrollo, según desarrollo y pruebo, veo si el ofuscado es correcto y todo funciona sin problemas.

Así que me decido a hacer el experimiento tanto con Gradle como con Maven en mi IntelliJ IDEA.

Proguard con Maven

Tienes el resultado en Proguard con Maven. Me llevó un rato, pero sin demasiados problemas.

  • Poner el Plugin proguard-maven-plugin
  • Decir que se ejecute durante la fase package de Maven
  • Poner el Plugin build-helper-maven-plugin para indicar que el jar ofuscado generado, con apellido classifier small debe ser tratado como un segundo artifact del proyecto

Cree un proyecto maven padre con dos hijos, el de la librería que quiero ofuscar y del que he contado todo esto y luego un segundo hijo con un proyecto main que usa la librería ofuscada. Ahi puse la dependencia del jar ofuscado, básicamente, añadiendo <classifier>

IntelliJ me costó un poquito más configuarlo. Básicamente en la configuración de Run tuve que poner que ejecutara la tarea maven verify antes de la tarea build propia de IntelliJ. Eso me aseguraba que se construía el jar ofuscado cada vez.

Y todo bien. Toco los fuentes de mi código que se va a ofuscar, ejecuto desde IntelliJ el main y todo va bien. Se ejecuta Proguard y el main corre con el código ofuscado (lo veo en el log, por el nombre de las clases y métodos

09:32:41.606 [main] INFO com.chuidiang.examples.proguard_library.a.a – Toy sumando numeros

Fíjate que saca el log con el paquete »a», clase »a»

Proguard con Gradle

Esto si fue una odisea. Son las cosas de Gradle. Muy versátil, tanto, que cuesta hacerlo funcionar. Tienes el resultado en Gradle con Proguard.

Lo primero, que no me pasó con Maven, es que tras poner el plugin proguard-gradle y configurarlo, es que daba un error sin ninguna explicación. Poniendo la opción -i de gradle y verbose en la configuración de Proguard, ya si sale el error:

java.io.IOException: Please correct the above warnings first

y no hay más errores. La opción de gradle –stacktrace muestra la excepción pero tampoco da pista. Por un IOException esperaba que me diera el nombre de un fichero o qué IO le estaba dando el error.

Google y resulta que hay que poner en un libraryjars de Proguard las dependencias que hayas puesto en tu fichero build.gradle. Como no queremos ponerlas una a una, más google y encuentras un «gradle’s truco»

libraryjars configurations.findByName(‘runtimeClasspath’).getFiles()

Vale, ya soy capaz de crear el jar ofuscado con el comando gradle y lanzando la tarea de ofuscación que he creado. Ahora me queda hacer que se ejecute automáticamente al generar el jar. Sin mucho problema.

Ahora viene la parte de IntelliJ. El primer problema es la dependencia. Si en mi subproyecto de main pongo la depencia de esta forma

implementation project(‘:library’)

No soy capaz de decirle que use el jar ofuscado en vez de el normal. O al menos, no he encontrado la forma. Y si lo pongo como jar de terceros

implementation «com.chuidiang.proguard:library:${project.version}:small»

Pues gradle no lo encuentra. Para Gradle es neceario que este jar esté un un repositorio accesible (maven central, maven local, ….). Así que la solución pasa por poner el plugin maven-pulish , configurar los publishing y hacer que se publique ese jar en maven local al compilar.

Así que toca el lío de que la tareas proguard y publishMavenPublicationToMavenLocal se ejecuten en el orden adecuado de forma automática.

Con todo esto, al final quedó conseguido. En IntelliJ, en la configuración de Run, tuve que añadir la tarea previa a la ejecución de gradle jar. Esta tarea es estándar de gradle y tal cual hemos configurado en build.gradle es la que lanza todo lo demás (proguard y publish).

Resumiendo

Resumiendo, lo habitual. Tanto con Gradle como con Maven conseguí hacerlo. Con Maven me llevó una horita tenerlo todo montado y funcionando. Con Gradle un día entero.

Publicado en gradle, maven, proguard | Etiquetado , , | Deja un comentario

Java switch e instanceof Pattern Matching

Logo de Java

LLevo programando en Java lo menos desde el 2000. Recuerdo empezar con Java 1.2, que pasó a llamarse Java 2 y que tenía Swing como gran novedad, «reemplazando» AWT. Desde entonces y de forma más o menos contínua, en el curro programo en Java.

Todo esto hace que tenga ya mis formas de hacer las cosas, con las que me encuentro cómodo, y que no ande muy pendiente de las nuevas novedades que van saliendo en las nuevas versiones. Pero me voy tropezando con código que hace gente más joven o que encuentro por internet. Aunque algunas cosas me parecen alternativas dudosas, como el tema de lambdas y fluent apis, otras veo que claramente son útiles.

Y aunque son «antiguas» (Java 17), dejo aquí un par de mejoras en instanceof y en switch

Java Instanceof Pattern Matching

Algo frecuente de tener que hacer es comprobar el tipo de una objeto que te llega para convertirlo al tipo adecuado. En mi forma tradicional, hacía cosas como esta

if (value instanceof String) {
   String aString = (String)value;
   // Usamos aString como String en lo que necesitemos
}

Desde Java 17, ahora es posible hacerlo de una forma más directa

if (value instanceof String aString) {
   // Nos ahorramos el cast, ya tenemos aString como String
}

Java Switch Pattern Matching

Quizás no tan frecuente, pero relacionado con lo anterior. Si tenemos posibilidades de que el objeto que nos pasan sea de varios tipos posibles, antes había que hacer un if para casa caso. Ahora switch nos permite hacerlo más fácilmente.

switch (value) {
    case Integer anInteger :
        System.out.println("Es entero "+anInteger);
        break;
    case String aString:
        System.out.println("Es string "+aString);
        break;
    case Double aDouble :
        System.out.println("Es double "+aDouble);
        break;
    default:
        System.out.println("Ninguno de los anteriores");
}

Así que ya sé alguna nueva cosa útile que ahorra código y, lo más importante, el firme propósito de revisar las novedadees tanto de las versiones de java que no he revisado como de las nuevas.

Publicado en java | Etiquetado , , , | Deja un comentario

Record en Java 14

Logo de Java

No suelo mirar en cada versión de Java qué novedades hay. Más bien me suelo tropezar con ellas. Y la última con la que me he tropezado son los record, de java 14 en adelante

Qué es un record en Java. Un ejemplo de record

public record Registro(int a, String b) {
}

Esto crea una clase Java, de nombre Registro, con dos campos int a y String b. Pero esa clase tiene una serie de particularidades

Tiene un constructor con dos parámetros, a y b

Los campos a y b son inmutables, es decir, una vez construida la clase, no podemos cambiar su valor

Tiene getter, aunque no cumplen la nomenclatura estándar. Son registro.a() y registro.b(). Como son inmutables, no hay setter

Tiene una implementación por defecto de hashcode(), equals() y toString() que contemplan todos los campos (a y b)

Para qué sirve un record en Java

Pues tiene una utilidad muy relativa. Es una forma sencilla de construir una estructura de datos que no se pueden modificar

Así que sirve principalmente para pasar datos de un lado a otro, pero que no necesiten ser modificados, ya que es inmutable. Y para esos casos, es una forma sencilla de definir esa estructura de datos.

Constructores y métodos en un record en Java

Podemos dar lógica al constructor por defecto de record, que lleva dos parámetros o definir otros constructores

public record Registro(int a, String b) {
    public Registro(int a, String b){
        if (null==b){
            throw new IllegalArgumentException();
        }
        this.a=a;
        this.b=b;
    }
    public Registro (int a) {
        this(a,"");
    }
    public Registro(){
        this(0,"");
    }
}

Hemos añadido lógica al constructor con dos parámetros para que no admite un null como parámetro b. Hemos añadido un constructor con un solo parámetro y sin parámetros, que llaman al constructor con dos parámetros dando valores por defecto.

Podemos también añadir otros métodos. Lo único es que en esos métodos no podemos modificar los valores de a y b, ya que internamente están definidos con final.

Publicado en java | Etiquetado , , | Deja un comentario

Apache Kafka Listeners y Advertised Listeners

Logo de Apache Kafka

He empezado a jugar, investigar y escribir alguna cosilla sobre Apache Kafka. Lo utilicé hace ya unos años, pero siempre me lo habían dado configurado y yo únicamente programaba clientes productores/consumidores.

Al ponerme a investigar cómo instalar Apache Kafka con Docker me he encontrado con un montón de parámetros de configuración, algunos de ellos muy parecidos y poco clara su utilidad, en concreto KAFKA_LISTENERS, KAFKA_ADVERTISED_LISTENERS y KAFKA_LISTENER_SECURITY_PROTOCOL_MAP. Detrás de ellos, unos cuantos derivados como KAFKA_INTER_BROKER_LISTENER_NAME y KAFKA_CONTROLLER_LISTENER_NAMES

Vamos a ver qué son y por qué tantos

Problema con los Listener de Kafka

Si instalamos uno o más nodos de Apache Kafka en cluster, dentro de una única red y en el que todos los clientes van a acceder también desde dentro de esa red, no hay mucho problema. Cada nodo estará accesible desde kafkaN:9092 o como queramos configurarlo, siendo kafkaN el nombre del nodo concreto en la red y 9092 el puerto que queramos poner.

El problema surge si varios de esos nodos están en redes distintas y/o los clientes acceden desde redes distintas. Es posible que el acceso a un nodo no sea igual desde dentro de una red que desde otra.

Un ejemplo claro es si montamos en cluster de nodos Kakfa en una red de contenedores docker pero algún cliente va a correr en el host anfitrión. En este caso, es normal publicar el puerto 9092 en el host anfitrión con la opción -p 9092:9092 del contenedor. Desde dentro de la red de dockers podemos acceder al nodo con kafkaN:9092, pero desde el host anfitrión accederíamos con localhost:9092.

Hasta ahora esto no sería un problema si no fuera por el siquiente comportamiento de Kafka. Cuando el cliente se conecta desde el host anfitrión con localhost:9092, lo primero que hace es preguntarle a Kafka cual es el nodo principal y Kakfa le contesta con la IP/nodo y puerto del nodo principal. En nuestro ejemplo, le contestaría con kafkaN:9092. Nuestro host anfitrión iría a ese nodo:puerto a seguir la comunicación, pero no la tiene accesible.

Veamos como resolver todo esto con los parámetros de configuración de arriba.

KAFKA_LISTENERS

En esta propiedad ponemos los puertos e interfaces de red por los que tiene que escuchar el broker de Kafka. Podemos poner tantos como nos hagan falta y en la misma propiedad ponemos un nombre de nuestro gusto a esa esccuha. Por ejemplo

KAFKA_LISTENERS: ‘LISTENER_INTERNO://:9094,LISTENER_EXTERNO://:9092’

Hemos dicho a Kafka que abra dos puertos, el 9092 y el 9094. Para identificarlos en las siguientes propiedades, les hemos puesto los nombre LISTENER_INTERNO, para la red interna de dockers y LISTENER_EXTERNO, para el host anfitrión. Si tenemos otras configuraciones de red o necesidades, podemos definir aquí los que queramos con los nombres y puertos que queramos.

En el formato podríamos poner, por ejemplo, LISTENER_INTERNO://<IP>:9094 siendo la IP la de la interface de red por la que queramos que se ponga a la escucha. Si no ponemos nada (como en el ejemplo) o ponemos 0.0.0.0, se pone a la escucha de todas las interfaces de red disponibles.

KAFKA_ADVERTISED_LISTENERS

En esta propiedad debemos decir qué IP y puerto debe comunicar Kaka a sus clientes para que puedan conectarse correctamente. Esta IP puerto puede ser distina según sea alguien interno a la red de dockers o alguien del host anfitrión.

Imagina que usando las opciones de docker, hemos publicado el puerto 9092 en el puerto 29092 del host anfitrión y que al host docker le hemos puesto de nombre kafkaN. Esa propiedad podría quedar así

KAFKA_ADVERTISED_LISTENERS: ‘LISTENER_EXTERNO://localhost:29092,LISTENER_INTERNO://kafkaN:9094’

Para los que se conecten al puerto 9092 (LISTENER_EXTERNO, es decir, host anfitrión), KAFKA les dirá que deben hacerlo a través de localhost:29092. Para los que se conecten al puerto 9094 (LISTENER_INTERNO, es decir, dentro de la red interna de docker) deben hacerlo con kakfaN:9092

KAFKA_INTER_BROKER_LISTENER_NAME

Los distintos broker de Kafka se conectan entre ellos para intercambiar información. Como hemos abierto dos puertos, uno para listener internos y otro para externos, debemo indicar aquí a Kafka cuál debe usar para interconexión entre nodos. Habitualmente es el de la red interna. Un ejemplo podría ser como lo siguiente

KAFKA_INTER_BROKER_LISTENER_NAME=LISTENER_INTERNO

KAFKA_CONTROLLER_LISTENER_NAMES

Este es sólo necesario si usamos KRaft en vez de Zookeeper. Usando KRaft, los mismos servidores Kafka tienen un protocolo entre ellos para decidir cual de ellos hace de controlador principal del cluster.

Para los controladores debemos seguir una lógica similar a los Listener. Es decir

  • En KAFKA_LISTENER definir un puerto adicional para atender a los demás broker del cluster. Además de los dos que ya tenemos, añadimos algo como CONTROLLER://9093.
  • En KAFA_CONTROLLER_LISTENER_NAMES debemos indicar cual de los tres listener que hemos abierto (interno, externo y controller). Es decir, KAFA_CONTROLLER_LISTENER_NAMES=CONTROLLER

Publicado en Kafka | Etiquetado , | 2 comentarios

Jugando con Elasticsearch y Java

En el curro estamos empezando a usar Elasticsearch para algunos temas. Como a mí en concreto no me ha tocado, me ha dado por hacer algunas pruebas por mi cuenta, desde Java, y así aprender lo básico.

Llevo un par de días con ellos … y no sé si me convence. No Elasticsearch en sí, no he hecho pruebas de rendimiento, ni con clusters ni nada de nada. Sólo con la API de Java.

¿Y por qué no me convence?. Varios motivos.

Fluent builders de la API Java de Elasticsearch

La web de Elasticsearch, respecto a la nueva API de Java, pone

Use of fluent builders and functional patterns to allow writing concise yet readable code when creating complex nested structures.

básicamente, que como se usan «fluent builders», las estructuras complejas anidadas se hacen más concisas y legibles. Aquí un ejemplo de código de la documentación.

// Search by product name
Query byName = MatchQuery.of(m -> m 
    .field("name")
    .query(searchText)
)._toQuery(); 

// Search by max price
Query byMaxPrice = RangeQuery.of(r -> r
    .field("price")
    .gte(JsonData.of(maxPrice)) 
)._toQuery();

// Combine name and price queries to search the product index
SearchResponse<Product> response = esClient.search(s -> s
    .index("products")
    .query(q -> q
        .bool(b -> b 
            .must(byName) 
            .must(byMaxPrice)
        )
    ),
    Product.class
);

Pues como promete la documentación, es una sintaxis «sencilla» y sobre todo «legible» para consultar productos con un nombre concreto y un precio máximo. No quiero ni imaginarme cómo será una consulta con más condiciones.

Documentación escasa

La documentación oficial es muy escueta, poco o nada didáctica. Las búsquedas por google tampoco dan mucha más información más allá de la documentación oficial. Quizás porque esta API de Java es relativamente nueva en Elasticsearh, antes se usaba directamente una API REST.

Si te fijas en el ejemplo anterior, para buscar por nombre usa MatchQuery y para lo del precio máximo RanqeQuery. Más allá del Javadoc, no he encontrado un tutorial «didáctico» donde te explique las alternativas que hay, cómo se usan, etc.

En fin, toda una odisea de búsqueda de documentación, prueba, ensayo y error como quieras hacer algo más allá de una consulta simple.

Aunque no sea exactamente de la API de Java, reto a alguien a que me diga que roles son los que hay que poner al crear un usuario que quieras que haga las típicas operaciones CRUD. Aquí tienes la lista de roles predefinidos.

Dichosa caché

En mis pruebas, un main sencillo, todo seguido: crear un índice, insertar, hacer un search para consultar lo insertado …. y la consulta no devuelve nada. Mirando directamente con el navegador web conectado a la URL de Elasticsearch veo que los datos sí se han insertado.

Un buen rato probando la consulta, por id de objeto insertado con get() funciona, con search() y condiciones no funcina, pongas lo que pongas…. pero de forma aleatoria, alguna vez sí va.

Así que sospechando de algo similar al commit que se hace con las tradicionales SQL, veo que hay un elasticsearchClient.indices().flush(). Tampoco va. Pero si después de eso pones un sleep() entonces ya funciona todo.

Es decir, tiene pinta de que en el mismo programa, con la misma instancia de elasticearchClient hay alguna caché que es distinta para cada operación y lo que insertas en una línea, no está disponbile para consulta en la siguiente.

Hay dos clases cliente de Elasticsearch. Una es síncrona y la otra asíncrona. La síncrona teóricamente te devuelve el control una vez ha terminado la operación, la asíncrona te lo devuelve inmediatamente aunque no haya terminado la operación.

¿Con cual de las dos crees que me estaba pasando lo de insertar y no tener disponibles los resultados?

¡¡Efectivamente, lo has adivinado!!. ¡¡Con la SINCRONA!!.

Una lanza a favor de Elasticsearch

En el curro, como comento, lo están usando. Pero lo usan en combinación con Kibana, o con clusters de nodos por el tema de alta disponibilidad, etc. Parece que en ese sentido la gente está muy contenta.

El uso que están dando es el almacenamiento masivo de información procedente de sensores desde uno o varios ejecutables separados. Luego con Kibana o bien con una aplicación hecha a medida, las consultas de esos datos históricos. Con Kibana no hay que pelearse con las consultas. Con la aplicación a medida seguramente topes con el primer problema que he comentado, pero todo es cuestión de pelearse y acostumbrarse.

En cuanto a cluster de nodos, parece que dos grupos de trabajo que lo han probado por separado e implementado en sus proyectos han quedado contentos con su comportamiento.

Conclusión

Pues lo dicho, no parece adecuada para uso como una base de datos de trabajo normal. Pero sí parece adecuada para meter muchos datos en cluster y análisis a posteriori de dichos datos, bien con Kibana, bien con aplicaciones a medida.

Publicado en elasticsearch | Etiquetado , | 1 comentario

¿Es necesario usar isDebugEnabled()?

logo slf4j

Cuando vemos código que usa un sistema de log para mostrar los mensajes de la aplicación, suele ser habitual ver código como el siguiente

if (log.isDebugEnabled()) {
   log.debug("Hola, " + nombre);
}

¿Por qué se usa isDebugEnabled()?

El motivo de usar esta llamada es para evitar que se construya la cadena de texto a mostrar en el log si realmente no se va a mostrar. En el ejemplo anterior, no tiene sentido componer la cadena «Hola, «+nombre si no la vamos a mostrar porque el log de debug no está habiliado.

Así que si nuestro mensaje es de debug, ponemos primero el if para ver si dicho mensaje va a salir. Sólo construimos la cadena si va a mostrarse.

En este ejemplo, construir la cadena no es muy costoso, pero puede haber cadenas a mostrar que requieran más variables, que las llamadas a toString() que hará java para esas variables no sean rápidas, quizás estén involucrados los antiguos StringBuffer que además están sincronizados.

Así que isDebugEnabled() se usa sólo por eficiencia. Evitar construir las cadenas de log si no van a mostrarse.

Por supuesto, tenemos variantes para los distintos niveles de log, como trace, info, warn, etc.

¿Pero es realmente necesario isDebugEnabled()?

Los nuevos sistemas de log, como slf4j, hacen esta llamada inútil. Eso sí, siempre y cuando no construyamos nosotros la cadena como en el ejemplo. Una llamada mejor, usando slf4j, sería la siguiente

if (log.isDebugEnabled()) {
   log.debug("Hola, {}", nombre);
}

Fíjate que en vez de construir la cadena como antes y pasar un único parámetro al método debug(), estamos pasando una cadena «Hola, {}» que tiene una pareja de llaves y luego estamos pasando un parámetro. Deberíamos pasar tantos parámetros como parejas «{}» hayamos puesto en la primera cadena.

slf4j irá reemplazando los «{}» por los valores de los parámetros que pasemos a continuación, en orden. Y lo mejor de todo es, que internamente, mirará si el log va a salir o no antes de hacer las operaciones para componer la cadena.

Así que como lo hace internamente, la llamada externa a isDebugEnabled() nos sobra totalmente, es redundante. Nos basta con

log.debug("Hola, {}", nombre);

Mucho más sencillo que ir poniendo un if antes de cada log ¿verdad?

¿Y si quiero sacar el log de una excepción?

En los métodos normales de otros sistemas de log se admitía un texto como mensaje y un segundo parámetro que fuera una excepción. La idea es que si se produce una excepción en nuestro código y la capturamos, podamos sacarla por el sistema de log

try {
   ...
} catch (Exception e) {
   log.error("Se ha producido un error", e);
}

Si ahora slf4j admite el mensaje con «{}» y todos los parámetros que queramos para reemplazar los «{}» con sus valores, ¿cómo sacamos la excepción?. Sencillo, nos basta ponerla como último parámetro. slf4j supondrá que si el último parámetro es de tipo Throwable, es una excepción que debe mostrar y no un parámetro para reemplazar una pareja «{}»

try {
   ...
} catch (Exception e) {
   log.error("Lo siento {}, se ha producido un error", nombre, e);
}

Conclusión sobre isDebugEnabled()

Así que la conclusión es que si usas sl4j y un formato de mensajes de log basado en cadenas con «{}» para reemplazar valores, NO necesitas usar isDebugEnabled().

Tu pregunta ahora será ¿Por qué usar slf4j?

Publicado en buenas costumbres de programación, slf4j | Etiquetado , , | Deja un comentario

Qué es SLF4J

logo slf4j

SLF4J, Simple Logging Facade For Java, es una abstración de un sistema de logging para una aplicación Java. Con esto queremos decir que no es un sistema de log completo, sino que simplemente nos sirve como «fachada» para hablar con otros sistemas de log. Por ejemplo, java.util.logging, log4j o logback.

Por qué necesitamos SLF4J

¿Y para qué necesitamos esta librería fachada?. De hecho, aparentemente complica más el asunto, porque necesitaríamos tres librerías de logger: La de SLF4J, la del logger concreto que queramos usar y un adaptador entre ambas.

Imagina que no estás haciendo una aplicación Java completa, sino sólo una librería o un módulo que quieres luego reaprovechar en otras aplicaciones. O incluso que quieres publicar para que usen otras personas.

Si en ese módulo usas tu logger favorito como podría ser logback o log4j, la aplicación completa que use este módulo estaría obligada a usar el mismo sistema de logger, o bien a tratar y configurar dos, el de tu módulo y el que se quiera usar la aplicación principal.

Esto, desde luego, puede no ser lo deseado en el primer caso y sería un engorro en lo segundo. La solución ideal es que el módulo no «obligue» a la aplicación a usar un sistema de log concreto. Y por eso SLF4J es útil en estos casos.

Cómo usar SLF4J

En tu librería añades la dependencia slf4j-api y la usas como un sistema de log normal. La aplicación que quiera usar tu librería es libre de decidir que sistema de log quiera usar. Por ejemplo, si quiere usar log4j, simplemente tendría que añadir la dependencia de log4j-core y un adaptador entre este y slf4j, que sería la librería log4j-slf4j-impl. Todo el log de tu libreria con slf4j-api será redirigido a log4j-core.

En el caso de logback, tienes logback-classic, que ya tiene incluido el adaptador. Por ello, bastaría sólo con esta dependencia.

Si en tu librería tienes test de JUnit o pequeños main de prueba, no tendrás sistema de log. SLF4J no funciona solo, necesita que le pongas un sistema de log concreto y el adaptador. Así que para estos test de JUnit o programas de prueba, necesitas añadir la dependencia de test tanto del sistema de log concreto como del adaptador.

Para facilitar esta tarea, slf4j proporciona su propio sistema de log simple, llamado slf4j-simple. Bastaría que lo añadas como dependencia de test si no quieres complicarte la vida con otros log más completos. En cualquier caso, para este propósito de test, logback-classic también es sencillo de usar puesto que lleva el adaptador incluido y por defecto no necesita ningún fichero de configuración.

Qué problemas podemos encontrar con SLF4J

Cuando hacemos nuestra librería, a nivel de uso, no deberiamos encontrar ninguno. Como mucho, que alguna funcionalidad muy específica de algún sistema de log concreto no esté accesible desde SLF4J, pero serían casos muy raros y concretos. Tampoco creo que sea algo muy recomendado que una librería que pretendes que sea útil en varios proeyectos use cosas muy concretas de un sistema de log muy concreto.

Sin emabargo, cuando alguien haba una aplicación usando nuestra libería, puede encontrar algún problema.

Failed to load class «org.slf4j.impl.StaticLoggerBinder». Es encesario que en la aplicación tengamos una librería adaptador. Si no se pone en las dependencias, aparecerá este error indicando que no la encuentra. Es lo que puede pasar también en nuestros test de JUnit de la libería si no ponemos como dependencia de test el log y el adaptador.

Class path contains multiple SLF4J bindings. Este error sale en caso de que se pongan dependencias de varios adaptadores, por el motivo que sea. Se deben revisar dependencias y dejar sólo uno. Realmente el error es un Warning. slf4j elegirá cualquiera de los adaptadores. Y ya conoces a Murphy, elegirá el que no queríamos que cogiera.

Este error, si no es por un despiste nuestro, puede dar guerra. Por desgracia, hay librerías y frameworks muy extendidos que no usan SLF4J, sino que de alguna forma usan su propio sistema de log. O que usan SLF4J pero vienen además con el sistema de log y el adaptador que ellas han decidido. Por ejemplo, apache storm-core viene con slf4j, log4j y su adaptador. Si necesitas usar storm-core dentro de tu aplicación y no quieres usar log4j, tienes un problema.

Problemas de versiones. Puesto que hay tres librerías implicadas: slf4j, el log concreto y el adaptador, es importante asegurarse que las versiones son compatibles entre sí. La mejor forma es buscar el adaptador en mvnrepository y ver sus dependencias. Por ejemplo, si miras el adaptador log4j-slf4j-impl, versión 2.22.0, verás que usa log4j versión 2.22.0 y slf4j-api versión 2.0.9. No suele haber problemas con pequeñas diferencias de versión, pero asegúrate que no sean versiones muy distintas o de revisarlo en caso de que el log te haga «cosas raras».

Publicado en log4j, logback, slf4j | Etiquetado , , , | Deja un comentario

Ephemeral ports

windows logo

Desde hace tiempo usamos ActiveMQ en el curro, embebido en Spring. Una cosa que nos pasaba esporádicamente en nuestros ordenadores de desarrollo es que ActiveMQ no arrancaba. Daba error de que su puerto por defecto, el 61616 ya estaba en uso. Vamos, el típico error

Cannot bind port 61616: Address already in use!

Por más que hacías un netstat para ver si el puerto realmente estaba en uso, no había nadie utilizando dicho puerto. Intentos sucesivos de arrancar la aplicación fallaban con el mismo error. Y reiniciando el ordenador entero, solía arreglarse y ya no fallaba…. hasta que aleatoriamente y de forma bastante esporádica, en otro arranque del PC, ya no funcionaba.

Así que la última vez que me pasó, hace un par de días y tras reiniciar el ordenador ver que el problema no se arreglaba, decidí investigar en serio. Costó algo encontrar la información, pero ahí va.

La culpa es de los ephemeral ports

Parece ser que los sistemas operativos, tras su arranque, se reservan una serie de puertos para establecer las comunicaciones y no dejan usarlos aunque no los estén usando ellos. Suelen ser bloques seguidos de 10 puertos dentro de un rango grande. Estos puertos son los que se conocen como ephemeral ports.

En el caso de Windows, mi caso, elige esos puertos de forma aleatoria en cada arranque dentro del rango 49152-65535. Y el puerto 61616 de ActiveMQ está ahí dentro, así que es candidato a que en algún arranque el sistema operativo lo pille y ActiveMQ no arranque. Linux usa otro rango, pero también hace algo parecido.

El comando windows

netsh int ip show excludedportrange protocol=tcp

nos muestra qué puertos ha pillado el sistema operativo y no podremos usar, aunque estén libres. La salida de este comando podría parecerse a la sigiuiente

Puerto de inicio Puerto final
———- ——–
80 80
8005 8005
21112 21112
50000 50059 *
50060 50159
61510 61609
61610 61709 <– Justo el 61616 cae en este rango
61910 62009
62010 62109
62110 62209
63442 63541

  • – Exclusiones de puertos administrados

Hay varias soluciones a este problema. Una, desde luego evidente, es configurar ActiveMQ para que use otro puerto fuera del rango 49152-65535 de puertos que podría querer reservar Windows

Tenemos otra opción para solucionar el problema en el momento que nos ocurra, sin necesidad de reiniciar el ordenador, pero desde luego, no es la mejor solución. La comento por si fuera de utilidad en algún momento.

Desde un terminal de comandos windows con permisos de super usuario, sería ejecutar los siguientes comandos

net stop winnat
Arrancar nuestra aplicación
net start winnat

net stop winnat para el servicio Windows Nat Driver (winnat), que es el que suele reservar esos puertos. Parando el servicio, se liberan los puertos. Podemos entonces arrancar nuestra aplicación sin problemas. Luego volvemos a arrancar el servicio winnat que pillará otros puertos que estén libres.

La solución más permanente, si no puedes cambiar en tu aplicación el puerto de ActiveMQ (o el que te esté dando problemas), es reservar tú ese puerto para que windows no lo reserve en el arranque. Para ello, con un terminal de comandos de windows con permiso de super usuario puedes ejecutar el comando

netsh int ipv4 add excludedportrange protocol=tcp startport=61616 numberofports=1

Eso reserva 1 puerto (numberofports) a partir del puerto 61616 (starport). Puedes reservar un bloque algo más grande por seguridad, por ejemplo, 20 puertos a partir del 61610 o lo que consideres. Esta orden permanece en arranques sucesivos del PC, por lo que no tienes que ejecutarla cada vez.

Para ejecutar este comando es importante que esos puertos estén libres en ese momento. Si no lo están, tendrías que parar temporalmente winnat como has visto antes.

Los puertos que hayas reservado aparecen en el listado anterior con un * detrás, como en el primero ejemplo es el rango 50000 a 50059.

Publicado en trabajo, windows | Etiquetado , , , | Deja un comentario

Jugueteando con el SEO

logo de seo

Mirando cosas en general por youtube, me encontré con los videos de Romuald Fons. Explicado de una forma muy peculiar, que no sabes muy bien si es un vende humos o realmente sabe, explica cosas de SEO (Search Engine Optimization). Al final sacas las ideas generales claras, pero te quedan muchas dudas sobre los detalles. Ves también con otros expertos SEO que hay bastantes discrepancias entre ellos con esto de los detalles.

La idea principal está clara. Cuando alguien busca algo en internet, lo hace con un objetivo (intención de búsqueda lo llaman) y google tenderá a ponerle primero aquella página que cumpla con dicho objetivo. Si buscas «cómo leer un fichero en java», google te pondrá primera aquella página que considere que explica mejor este tema concreto.

Pero como me quedaron dudas con los detalles, me decidí jugar a experimentar. Y como tengo una wiki de programación, pues ya tengo las herramientas para jugar.

¿Cuál es el resultado de todo esto?. Pues ni idea, llevo poco más de un mes jugueteando y no noto nada especial en las visitas, ni mejor ni peor. También un mes quizás es poco, por ahí mencionan que igual los resultados empiezan a verse tres meses después.

Pero si hay un resuttado «secundario» y es que me he liado a arreglar tutoriales viejos y escribir otros nuevos como un loco. Llevo un mes largo de actividad constante en una wiki que casi tenía abandonada. Y eso también lleva a muchos «commit» en mi git de ejemplos.

A modo de resumen:

Así que nada, de momento estoy «motivado» y sigo escribiendo cosas como loco. Aunque sigo intentando hacer SEO, al final me puede el espíritu de programador y me lío con tutoriales que sé que no tienen demasiado interés, pero que me presentan problemas que quiero entender o resolver. Por ejemplo, quién va a tener interés en saber cómo se hace un Doclet en Java. Muchos programadores java no saben qué es eso, así que muchos menos lo van a buscar en google.

Publicado en google, web | Etiquetado , , | Deja un comentario