Archivo de la categoría: Taller tecnológico

Post técnico #7: Solucionar problema reproducción de video HTML 5 con Firefox en Fedora

Tras la última actualización (a la fecha de publicación de este post) de la librería ffmpeg en la distribución GNU/Linux Fedora (24), la reproducción de videos en Youtube desde mi Firefox empezó a fallar, mostrando primero el mensaje “Se ha producido un error, vuelve a intentarlo más tarde (ID de reproducción: “W#E$R%TY!Q)” y luego la reproduccin saltaba a Flash Player. Si tu sistema presenta estos mismos sintomas, tal vez esto te pueda ayudar.

  • Entra a Firefox y digita esto en la url: about:config. Esto te mostrará una pantalla advirtíendote del riesgo de modificar la configuración del navegador. Dile que aceptas el riesgo (en el respectivo botón).
  • Aparecerá una pantalla con un gran listado de configuraciones. En la barra de búsqueda digita media.ffmpeg.enabled, lo cual filtrará el listado, quedando una única opción cuyo valor es true.
  • Dale doble click a esta opción, para deshabilitar la reproducción de medios vía FFMPEG. La opción ahora debería tener el valor false y su texto quedar en negrita (indicando que el valor de dicha configuración fue alterado).

Listo, prueba de nuevo en Youtube y con algo de suerte te funcionará de nuevo el reproductor HTML5. Ese fue mi caso.


Post técnico #6: Una intercepción por clase; el Same interception type cannot be specified twice on the same class

A veces por no leer la documentación de las API surgen errores que nos hacen perder el pelo. Para la muestra un botón: después de llevar un buen rato de desarrollo haciendo un interceptor de EJBs, intenté subir la aplicación y el resultado fue el siguiente:

Grave: Exception while loading the app : Same interception type cannot be specified twice on the same class org.jboss.weld.interceptor.util.InterceptorMetadataException: Same interception type cannot be specified twice on the same class at org.jboss.weld.interceptor.reader.InterceptorMetadataUtils.
buildMethodMap(InterceptorMetadataUtils.java:136) at org.jboss.weld.interceptor.reader.InterceptorMetadataUtils.
readMetadataForTargetClass(InterceptorMetadataUtils.java:43) at org.jboss.weld.interceptor.reader.cache.DefaultMetadataCachingReader$2.
apply(DefaultMetadataCachingReader.java:36) at org.jboss.weld.interceptor.reader.cache.DefaultMetadataCachingReader$2.
apply(DefaultMetadataCachingReader.java:34) at com.google.common.collect.ComputingConcurrentHashMap$
ComputingValueReference.compute(ComputingConcurrentHashMap.java:355)…

Después de indagar en la web y encontrar soluciones como por ejemplo que las anotaciones @PostConstruct o @PreDestroy estaban repetidas en alguno de los beans manejados por el contenedor, sospeché sobre la anotación @AroundInvoke (que en últimas era la única herramienta nueva había sido incluida en el último desarrollo) y revisé su documentación, en donde encontré la respuesta:

A class must not declare more than one AroundInvoke method

El caso era que en el código había una sola clase con cuatro métodos empleando la anotación @AroundInvoke. Grave error. Separándolos en cuatro clases diferentes el problema se solucionó (si alguien conoce una mejor forma de solucionarlo, por favor no deje de comunicarnoslo).


Post técnico #5: Soporte para exFAT en GNU+Linux Fedora

Para dar soporte al privativo sistema de archivos exFAT en GNU+Linux, con el cual se encuentran formateados muchos dispositivos de almacenamiento USB, se deben instalar los paquetes fuse-exfat y exfat-utils. Estos paquetes se encuentran en los repositorios de RPM-Fusion:

su -c 'yum install fuse-exfat exfat-utils'

Esto instalará una implementación libre del sistema de archivos exFAT a través de FUSE.

Con esto rompemos un nuevo muro tecnológico impuesto por la industria neoliberal de la tecnología.

PD: Si no tienes instalados los repositorios de RPM-Fusion, instalalos mediante este comando y luego podrás instalar fuse-exfat:

su -c 'yum localinstall http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-18.noarch.rpm'


Post técnico #4: Configurar archivo de identidad (clave privada) específico en SSH

Cómo crear claves para poder conectarse a un servidor remoto mediante SSH es una explicación ampliamente difundida en Internet. Para la muestra estos casos:

En estas explicaciones se puede ver cómo es creado un par de llaves: una pública (id_dsa.pub, la cual se comparte con el resto del mundo) y una privada (id_dsa). Si es así, todo funciona bien. Pero cuando se nos ocurre cambiar el nombre de tal par de archivos o ubicarlos en subdirectorios dentro del mencionado directorio ~/.ssh (para sistemas GNU/Linux) entonces la cosa deja de ir bien.

Lo que ocurre entonces es que el servicio ssh, cuando va a autenticar nuestra clave pública alojada en el servidor contra nuestra clave privada (ubicada ahora, por ejemplo, en ~/.ssh/clave-empresa/empresa_id_rsa) no puede encontrar nuestra clave privada o “archivo de identidad”. Después de algunos madrazos, se descubre que tenemos que hacer lo siguiente:

  1. Acceder en una consola como superusuario y abrir el archivo /etc/ssh/ssh_config con nano, vim o el editor preferido de cada quien. Por ejemplo, empleando VIM el comando sería así: su -c 'vim /etc/ssh/ssh_config'
  2. Agregar la siguiente linea después de la entrada Host *: IdentityFile ~/.ssh/clave-empresa/empresa_id_rsa (según nuestro ejemplo, pero el nombre del subdirectorio, si es que lo hay, y el del archivo de clave privada debe ser cambiado por el nombre que cada quien utilice). Así, la entrada dentro del archivo de configuración de SSH quedaría mas o menos así:

    ...
    # PermitLocalCommand no
    # VisualHostKey no
    # ProxyCommand ssh -q -W %h:%p gateway.example.com
    Host *
    IdentityFile ~/.ssh/clave-empresa/empresa_id_rsa
    ...

    Luego se guardan estos cambios, sobreescribiendo el archivo.

  3. Reiniciar el servicio ssh: su -c 'systemctl restart sshd.service'. Podemos comprobar su estado con el comando systemctl status sshd.service

Listo, ahora cuando el servicio SSH va a autenticar nuestra clave pública alojada en el servidor remoto contra nuestra clave privada (ubicada ahora, en nuestro ejemplo, en ~/.ssh/clave-empresa/empresa_id_rsa) la autenticación se llevará a cabo exitosamente. Cabe anotar que lo anterior funciona en la distribución GNU/linux Fedora. La ruta del directorio ssh en las otras distribuciones puede que varíe.

Por ahora dejamos aquí. Cualquier duda o comentario es bienvenido.


Post técnico #3: Carga dinámica de reglas en Drools y el mismatched input

Regularmente, cuando se trabaja con Drools, se cargan las reglas de negocio desde archivos .drl. Pero en ocasiones se necesita cargar las reglas de forma más dinámica o desde otras fuentes de datos, por ejemplo, una variable, una respuesta de un servicio web o un campo en una base de datos. Particularmente, cuando intenté leer las reglas y generar el conocimiento en Drools cargándolas desde un campo en una base de datos, en un entorno JEE6, PostgreSQL 9.1 y Drools 5.2.1, obtenía el siguiente error:

[ERR 101] Line 1:1188 no viable alternative at input ”
[ERR 102] Line 1:1188 mismatched input ‘<eof>’ in rule “Una regla de negocio”
Parser returned a null Package

Al indagar en la regla, la posición 1188 era el final de la misma, es decir, el último caracter. Después de darle muchas vueltas y no encontrar nada sospechoso, ni una pista, el editor de variables en tiempo de depuración de Netbeans me echó una mano: la regla no tenía el caracter de retorno de carro en los finales de linea, de manera que toda la regla era una sola línea. Al poner las respectivas finalizaciones de línea en su lugar dentro de la regla (en el campo dentro de la base de datos que contenía la regla) y leer de nuevo desde la base de datos, la generación del conocimiento fue exitosa y la regla pudo ser ejecutada.