Entradas etiquetadas con web profile

Servicio de arranque de JBossAS 7.0.2 para Linux

Recientemente tuve que realizar una instalación de JBossAS 7.0.2. Esta versión es la Web Profile de la rama 7, siendo la 7.1.1 la Full Profile. Por si no lo recuerdas, hace unas semanas publique un post explicando las diferencias entre ambos profiles. El caso es que ademas de diferenciarse en eso, también se diferencian en mas cosas, como por ejemplo que en la versión 7.1.1, en la ruta jboss-as-7.1.1.Final/bin/init.d/ podemos encontrar un script de arranque para Linux y que para la versión 7.0.2 dicha ruta no existe. Basándome en el de la 7.1.1 he realizado este script, que si bien es mejorable, te puede servir como punto de partida por si te piden instalar un 7.0.2. en modo standalone.

#!/bin/sh
#
# JBoss standalone control script
#
# chkconfig: 2345 80 20
# description: JBoss AS Standalone
# processname: standalone
# pidfile: /opt/jboss-as-web-7.0.2.Final/bin/jboss-as-standalone.pid
# config: /etc/jboss-as/jboss-as.conf

# Source function library.
. /etc/init.d/functions

# La variable JAVA_HOME la definimos en standalone.conf
# Load Java configuration.
#[ -r /etc/java/java.conf ] && . /etc/java/java.conf
#export JAVA_HOME

# Load JBoss AS init.d configuration.
if [ -z "$JBOSS_CONF" ]; then
  JBOSS_CONF="/opt/jboss-as-web-7.0.2.Final/bin/standalone.conf"
fi

[ -r "$JBOSS_CONF" ] && . "${JBOSS_CONF}"

# Set defaults.
if [ -z "$JBOSS_HOME" ]; then
  JBOSS_HOME=/opt/jboss-as-web-7.0.2.Final
fi

export JBOSS_HOME

# IP de escucha del servidor
JBOSS_IP=0.0.0.0
export JBOSS_IP

if [ -z "$JBOSS_PIDFILE" ]; then
  JBOSS_PIDFILE=/opt/jboss-as-web-7.0.2.Final/bin/jboss-as-standalone.pid
fi

export JBOSS_PIDFILE

if [ -z "$JBOSS_CONSOLE_LOG" ]; then
  JBOSS_CONSOLE_LOG=/opt/jboss-as-web-7.0.2.Final/standalone/log/console.log
fi

if [ -z "$JBOSS_USER" ]; then
  JBOSS_USER=jboss
fi

if [ -z "$STARTUP_WAIT" ]; then
  STARTUP_WAIT=30
fi

if [ -z "$SHUTDOWN_WAIT" ]; then
  SHUTDOWN_WAIT=30
fi

if [ -z "$JBOSS_CONFIG" ]; then
  JBOSS_CONFIG=standalone.xml
fi

JBOSS_SCRIPT=$JBOSS_HOME/bin/standalone.sh
prog='jboss-as'
CMD_PREFIX=''

if [ ! -z "$JBOSS_USER" ]; then
  if [ -x /etc/rc.d/init.d/functions ]; then
    CMD_PREFIX="daemon --user $JBOSS_USER"
  else
    CMD_PREFIX="su - $JBOSS_USER -c"
  fi
fi

start() {
  echo -n "Iniciando $prog: "

  if [ -f $JBOSS_PIDFILE ]; then
    read ppid < $JBOSS_PIDFILE     if [ `ps --pid $ppid 2> /dev/null | grep -c $ppid 2> /dev/null` -eq '1' ]; then
      echo -n "$prog se esta ejecutando"
      failure
      echo
      return 1
    else
      rm -f $JBOSS_PIDFILE
    fi
  fi
  mkdir -p $(dirname $JBOSS_CONSOLE_LOG)
  cat /dev/null > $JBOSS_CONSOLE_LOG
  mkdir -p $(dirname $JBOSS_PIDFILE)
  chown $JBOSS_USER $(dirname $JBOSS_PIDFILE) || true
  #$CMD_PREFIX JBOSS_PIDFILE=$JBOSS_PIDFILE $JBOSS_SCRIPT 2>&1 > $JBOSS_CONSOLE_LOG &
  #$CMD_PREFIX JBOSS_PIDFILE=$JBOSS_PIDFILE $JBOSS_SCRIPT &
  if [ ! -z "$JBOSS_USER" ]; then
    if [ -x /etc/rc.d/init.d/functions ]; then
      daemon --user $JBOSS_USER LAUNCH_JBOSS_IN_BACKGROUND=1 JBOSS_PIDFILE=$JBOSS_PIDFILE $JBOSS_SCRIPT -b $JBOSS_IP --server-config=$JBOSS_CONFIG 2>&1 > $JBOSS_CONSOLE_LOG &
    else
      su - $JBOSS_USER -c "LAUNCH_JBOSS_IN_BACKGROUND=1 JBOSS_PIDFILE=$JBOSS_PIDFILE $JBOSS_SCRIPT -b $JBOSS_IP --server-config=$JBOSS_CONFIG" 2>&1 > $JBOSS_CONSOLE_LOG &
    fi
  fi

  count=0

  launched=false

  until [ $count -gt $STARTUP_WAIT ]
  do
    grep 'JBoss AS.*started in' $JBOSS_CONSOLE_LOG > /dev/null
    if [ $? -eq 0 ] ; then
      launched=true
      break
    fi
    sleep 1
    let count=$count+1;
  done

  success
  echo
  return 0
}

stop() {
  echo -n $"Parando $prog: "
  count=0;

  if [ -f $JBOSS_PIDFILE ]; then
    read kpid < $JBOSS_PIDFILE     let kwait=$SHUTDOWN_WAIT     # Try issuing SIGTERM     kill -15 $kpid     until [ `ps --pid $kpid 2> /dev/null | grep -c $kpid 2> /dev/null` -eq '0' ] || [ $count -gt $kwait ]
    do
      sleep 1
      let count=$count+1;
    done

    if [ $count -gt $kwait ]; then
      kill -9 $kpid
    fi
  fi
  rm -f $JBOSS_PIDFILE
  success
  echo
}

status() {
  if [ -f $JBOSS_PIDFILE ]; then
    read ppid < $JBOSS_PIDFILE     if [ `ps --pid $ppid 2> /dev/null | grep -c $ppid 2> /dev/null` -eq '1' ]; then
      echo "$prog se esta ejecutando (pid $ppid)"
      return 0
    fi
  fi
  echo "$prog NO se esta ejecutando"
}

case "$1" in
  start)
      start
      ;;
  stop)
      stop
      ;;
  restart)
      $0 stop
      $0 start
      ;;
  status)
      status
      ;;
  *)
      ## Si no se indican parametros
      echo "Uso: $0 {start|stop|status|restart|reload}"
      exit 1
      ;;
esac

Nueva clasificación de los servidores de aplicaciones

Nuevos tipos de servidores

Hasta ahora, los servidores de aplicaciones java podían clasificarse en dos grandes grupos: contenedores de servlets (como puede ser Tomcat o Jetty) y servidores J2EE (JBoss, Weblogic o GlassFish entre otros). Hasta ahora, siempre pensábamos en los primeros como servidores ligeros, rápidos al arrancar, con poco overload… y en los segundos como servidores mas pesados, complejos y mas lentos en arrancar. Poco a poco, todo esto ha ido cambiando: como se pudo ver en el post donde analizaba los tiempos de arranque de las diferentes versiones de JBoss, estos tiempos se han ido reduciendo de forma constante.

Con la última versión de J2EE, la versión 6, esta clasificación ha cambiado. Siguen existiendo los contenedores de servlets pequeños y eficientes, pero los servidores J2EE propiamente dichos se han dividido en dos categorías: por un lado los Java EE 6 Full Profile y por otro los Java EE 6 Web Profile. Los servidores Web Profile implementan un subconjunto de características de los Full Profile: básicamente una parte de la especificación de los EJB, JPA y JTA. Estos los situaría en un punto intermedio de la clasificación que comentaba un poco mas arriba, entre los contenedores de servlets y los servidores J2EE.

¿Tiene sentido esta división?

En mi opinión, si. Hasta ahora, muchos desarrolladores eran reacios a utilizar servidores J2EE. Por un lado, su consumo de recursos es mayor. Por otro lado, para versiones de J2EE anteriores a la 6, la programación resultaba compleja. Para soslayar estos problemas, lo que han venido haciendo es utilizar un contenedor de servlets añadiendo librerías/frameworks de terceros (principalmente Spring e Hibernate) para conseguir esas funcionalidades que necesitaban. Este hueco es el que viene a llenar el Web Profile.

¿Como afectará esta nueva categoría al ecosistema?

Esto dependerá de como acepte la comunidad de desarrolladores la versión 6 de J2EE. Si buscáis en Google “J2EE6 versus Spring” veréis que hay una guerra abierta. Nos os perdáis los comentarios del post que aparece como primer resultado: “Why is Java EE 6 better than Spring ? (Arun Gupta, Miles to go …)” que ademas pertenece a un blog oficial de Oracle. En el caso de que mayoritariamente los desarrolladores continúen usando Spring (junto con otras librerías) veremos pocos cambios. Pero si el empleo de servidores Web Profile se extiende, creo que iremos viendo a los contenedores de servlets ir desapareciendo, salvo aquellos (como Tomcat) que se empleen embebidos en otros paquetes software.

¿Y entonces que hago?

Si trabajas en una empresa grande, muévete por el edificio y pregunta en desarrollo. Si te dicen que están dejando de usar Spring porque no quieren usar librerías para cosas que ya vienen incluidas en el servidor, empieza a mirar manuales de instalación de servidores Web Profile. Si trabajas en una empresa pequeña, tampoco te hará mal irlos mirando. En cualquier caso, permanece atento a este blog pues en próximas entradas seguiré ampliando el tema.

Ir arriba