Archivo de la etiqueta: Tecnología

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

Anuncios

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'


Engranando campo

Engranando campo

El maquinista

El maquinista

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.