Entradas etiquetadas con jboss

Cursos gratuitos de JBoss para desempleados

A través de javaHispano puedes informarte sobre estos cursos gratuitos y oficiales de JBoss a los que podrán acceder desempleados de Madrid:

  • JB248 – JBOSS Application Administration I.
  • JB225 – JBOSS Application Development I.
  • JB325 – JBOSS Application Development II.

Estos conocimientos, capacitarán para la obtención de las siguientes certificaciones:

  • RHCJA – Red Hat Certified JBoss Administration (EX248)
  • RHCJD – Red Hat JBoss Certified Developer (EX225).

Si tienes la oportunidad, te recomiendo que la aproveches.

WildFly ya esta presente en Fedora

Logo oficial de WildFly

Logo oficial de WildFly

Ya es posible instalar a través de la paquetería de los repositorios de testing de Fedora 20 la versión Alpha4 de WildFly 8. He hablado aquí bastantes veces de WildFly: se trata del JBossAS de toda la vida, solo que con otro nombre. Recuerda también que el paquete ya no se llama jboss-as sino wildfly (puede parecer una tontería, pero se puede perder mucho tiempo con esto :D).  Ademas, están intentando que con el lanzamiento de Fedora 20 (que esta planificado para noviembre) tengamos disponible la versión Final de WildFly 8.  Así que lo tendremos disponible dentro de poco y podremos ver si la estrategia de RedHat funciona y aumenta la cuota de mercado de su versión de pago: JBoss EAP.

RedHat libera JBoss EAP 6.1

Como hemos estado viendo estos meses atrás RedHat decidió reservar la marca JBoss, ya asentada con fuerza en el mercado, para su servidor de aplicaciones enterprise. Estos cambios ya se han producido y aquí tenemos la primera release de JBoss EAP 6.1.

Esta release ya no es accesible directamente desde la página de descargas de JBoss, pero puedes obtenerla gratuitamente si te registras. Eso si, solo con fines de desarrollo. Si todo este baile de nombres y números no me confunde, esta release se hubiera correspondido con la 7.2 siguiendo la numeración antigua. Para ver los cambios, solo tienes que mirar las release notes.

Por otro lado, la versión community ahora se llama WildFly, de la cual ya hemos hablado por aquí. Ya están disponibles las primeras versiones inestables de la rama 8. Esta pensada para ser JEE7 certificada. Así que tus opciones son las siguientes si quieres seguir usando la versión de la comunidad:

  • Explica muy bien a tus clientes que al JBossAS sin soporte le han cambiado el nombre. Explícales que es lo mismo de antes con otro nombre. Que si no tenían soporte para sus JBossAS, no lo necesitan para WildFly.
  • No vas a tener ninguna actualización para tus instalaciones de la versión 7. Para actualizarte tendrás que esperar a la versión 8 Final de WildFly, que ya no sera JEE6 sino JEE7.
  • Si tienes un bug en tu JBossAS7 de producción que necesitas solucionado obligatoriamente y no puedes esperar a la 8 de WildFly ve pensando en contratar soporte.

Yo seguiré pendiente de todos estos movimientos, así que si quieres enterarte de ellos conforme vayan sucediendo puedes probar a suscribirte al blog.

Hacer convivir varias instalaciones de JBossAS en el mismo servidor

En entornos de producción suele ser de lo mas corriente dedicar determinados servidores (físicos o virtuales) a la instalación de servidores de aplicaciones, de forma que encontremos instancias de Tomcat,  JBossAS e incluso WebLogic compartiendo recursos. Esto, como tantas otras cosas, dependerá de la forma en que se ha querido (o podido) ir organizando el servicio. Si se dispone de grandes maquinas con muchos procesadores y RAM, esta sera la tónica general. Si por el contrario se ha optado por virtualizar, sera mas común encontrarnos con máquinas virtuales mas pequeñas dedicadas casi en exclusiva a servir de soporte a un único servidor de aplicaciones.

Si nos centramos en el primer caso, donde tenemos una maquina donde conviven varios servidores de aplicaciones, tendremos que asegurarnos de que los puertos que utilizan cada uno de estos servidores no colisionan con los demás. Una primera aproximación, sería asignar puertos al azar. Por absurdo que parezca, he encontrado esta solución en algunos sitios: se asignaba el puerto de escucha de forma incremental (8080 al primero, 8081 al segundo…) pero el resto de puertos que abría cada servidor de aplicaciones era cambiado de forma aleatoria. La frase que justificaba tal decisión solía ser una variante de “Total, si aunque los abra, esos puertos no se usan…”. Lo primero que se puede argumentar ante esto es que si ese puerto no se usa, asegúrate de que no se abra. Lo segundo es que si algún día tienes un conflicto con los puertos, no vas a saber que servidores son los que colisionan.

La mejor forma de hacer esto consiste en sumar una determinada cantidad a todos los puertos que abre el servidor de aplicaciones, y no solo al puerto de escucha. Personalmente, recomiendo sumar 100 a cada puerto. Es una cantidad que te permite al hacer por ejemplo un netstat visualizar fácilmente a que servidor de aplicaciones corresponde cada puerto y evita las colisiones de los diferentes puertos, cosa que por ejemplo no soluciona el sumar 1.

En Tomcat esta tarea la tendremos que realizar manualmente. En JBossAS podemos hacerlo de forma automática, con un parámetro en el arranque. Esto nos facilitara el trabajo.

JBossAS 5 y 6

Con las versiones 5 y 6 de JBossAS, utilizaremos el parametro -Djboss.service.binding.set. Por ejemplo, si queremos sumar 100 a todos los puertos lanzaremos el servidor de aplicaciones con -Djboss.service.binding.set=ports-01. En el caso de querer sumar 200, cambiaremos el parametro a ports-02 y sucesivamente. Los valores de los puertos se definen en el fichero server/CONFIGURACION/conf/bindingservice.beans/META-INF/bindings-jboss-beans.xml, siendo CONFIGURACION el nombre de la configuración que estemos usando. Por defecto, se usa la configuración default.

JBossAS 7

Para la ultima version de JBossAS, esto ha cambiado y utilizaremos el parametro -Djboss.socket.binding.port-offset. Para sumar 100 a todos los puertos arrancaremos el servidor con -Djboss.socket.binding.port-offset=100. Esta forma de hacerlo es mas practica, aunque menos flexible.

Usando estas opciones, tu trabajo de administración sera mas cómodo y las instalaciones mas rápidas, reduciendo a la vez las posibilidades de que surjan errores y el tiempo necesario para resolverlos si aparecen.

Retraso en la elección del nuevo nombre de JBoss AS

Como muchos sabréis, Red Hat decidió hace unas semanas cambiar el nombre del servidor de aplicaciones JBoss, alegando que existía una cierta confusión entre el servidor de aplicaciones, otros componentes de la comunidad, e incluso la propia comunidad. Ayer, en el blog oficial de Mark Little, pudimos leer que debido al enorme número de nombres propuestos el anuncio del nuevo nombre no sera realizado hasta enero del año que viene. Habrá que esperar.

 

Mark Little encabeza la dirección técnica de JBoss, podéis encontrar mas información en su blog personal.

Ir arriba