Iniciar su Aplicación (Linux / UNIX)

En UNIX, es posible ejecutar una aplicación ya sea como una aplicación de escritorio, o como un proceso demonio en segundo plano. En el caso de un demonio el Wrapper necesita estar instalado, poder ser removido, reiniciado, detenido, tener su estado consultado, etc. Dependiendo si la aplicación tiene un GUI o si el próposito es que sea ejecutada en una ventana de comandos, esto también determinará como debe ser ejecutada.

  • Archivo Script Basado en Comandos - Proporciona un solo script de shell, que usa un comando como parámetro para desempeñar algunas acciones en el Wrapper. Scripts como estos son muy comunes en sistemas UNIX.
  • Binario Independiente - También es posible ejecutar el Wrapper binario directamente. En la mayoría de los casos, esto se hace desde la línea de comandos al proporcionar parámetros adicionales, pero es posible usar también un archivo de configuraciones predeterminado para evitar este tipo de requisitos.

Archivo Batch Basado en Comandos

Configuración de los Scripts

El Wrapper viene incluido con un archivo (sh) que se puede usar para iniciar y terminar cualquier aplicación Java controlada por el Java Service Wrapper.

El primer paso es copiar el siguiente shell script al directorio bin de su aplicación (en versiones anteriores del Wrapper, este archivo se llamaba 'sh.script.in').

Archivo Script: 
{WRAPPER_HOME}/src/bin/App.sh.in

Cambie el nombre del archivo script para reflejar el nombre de su aplicación. (Por favor, reemplaze "MyApp" con el nombre de su aplicación en todos los ejemplos en este documento.)

Ejemplo para reemplazar el nombre del archivo: 
/usr/lib/myapp/bin/myapp

Ahora, abra el script en un editor de textos:

Hay varias variables en el inicio del script que se pueden usar para configurar como el Wrapper debe ser lanzado. Cada una de ellas va precedida de una descripción explicando la forma de uso y los valores que se pueden utilizar. En la mayoria de los casos, se puede usar los valores predeterminados en un princípio, y después pensar en modificar algunas variables cuando surge la necesidad.

Desde la versión 3.5.37, el sript de shell buscará un carchivo con el mismo nombre base que el script, localizado en el mismo directorio, y con una extensión '.shconf'. Si dicho archivo existe, éste será ejecutado, haciendo posible anular cualquier variable del script de shell. Si necesita personalizar una variable, es buena práctica hacerlo en el archivo .shconf y dejar el archivo de script en su estado original. Al hacerlo, cualquier actualización del Wrapper será fácil, ya que solo necesitará reemplazar el script sin necesitar combinar sus modificaciones.

Ejemplo de nombres de archivos script y shconf: 
/usr/lib/myapp/bin/myapp
/usr/lib/myapp/bin/myapp.shconf

Tenga en cuenta que usted aún necesitará reemplazar el token en la sección 'INIT INFO' en la parte superios del script: 

### BEGIN INIT INFO
# Provides: @app.name@
# Required-Start: $local_fs $network $syslog
# Should-Start: 
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: @app.long.name@
# Description: @app.description@
### END INIT INFO

Entre las variables del script de shell, puede querer modificar al menos APP_NAME y APP_LONG_NAME para reflejar que el script está siendo usado para iniciar su aplicación. Si no se configura APP_NAME, se volverá por defecto al nombre de base el script de shell, y si APP_LONG_NAME no se configura, se volverá por defecto al valor de APP_NAME.

Ejemplo: 
APP_NAME="myapp"
APP_LONG_NAME="My Application"

El script asume que el wrapper ejecutable se localiza en es mismo directorio, y que el archivo wrapper.conf se localiza en un directorio conf (un nivel arriba, ../conf/wrapper.conf). Si desea colocar cualquier de esos archivos en otro directorio, las variables WRAPPER_CMD y WRAPPER_CONF necesitarán las modificaciones apropiadas.

ADVERTENCIA

Importante! Antes de continuar, asegúrese que el script, el archivo '.shconf' y el wrapper ejecutable tienen los bits ejecutables configurados.

NOTA

El script de shell (sh) tratará de crear un archivo PID en el directorio /var/run. Si el usuario que lanza el Wrapper no tiene el permiso para escribir en este directorio, el resultado será generado como error. Una alternativa que funcionará en la mayoría de los casos es escribir un archivo PID en el mismo directorio en el que el Wrapper esta ubicado. Para hacer estos cambios, edite el archivo sh y cambie la siguiente línea: 

PIDDIR="/var/run"

para: 

PIDDIR="./"

Ejecutar en una Consola

Iniciar la aplicación:

La aplicación ahora puede ser ejecutada con un comando simple bin/myapp console. Gracias a la manera con la que el script del Wrapper configura su directorio actual, no es necesario ejecutar este script desde el directorio bin.

Ejemplo de comando y salida de datos: 
/usr/lib/myapp/bin/myapp console
Running My Application...
wrapper  | --> Wrapper Started as Console
wrapper  | Launching a JVM...
jvm 1    | Wrapper (Version 3.x.x)
jvm 1    |

Cuando se ejecuta usando el comando console, la salida de datos de la máquina JVM será mostrada en dicha consola.

Detener la aplicación:

La aplicación puede ser terminada al presionar CTRL-C en la consola (ventana de comandos). Esto causará que el Wrapper apague la aplicación adecuadamente, es decir, de una manera "limpia".

Scripts estándar de procesos Daemon:

Como verá si omite un comando, los scripts incluidos con el Wrapper son scripts estandarizados de procesos demonio. Ellos acceptan los comandos console, start, stop, restart, status y dump.

  • Los comandos start, stop y restart son comunes para casi todos los scripts demonio y son usados para controlar el Wrapper y su aplicación como un proceso demonio.
  • El comando status se usa para determinar si el Wrapper está siendo ejecutado o no.
  • El comando console iniciará el Wrapper en el shell actual, haciendo posible terminar repentinamente la aplicación al pulsar CTRL-C.
  • El comando final, dump enviará una señal "kill -3" al Wrapper causando que la máquina JVM ejecute un vertedero de memoria (thread dump).

Ejecutar como un Proceso Demonio

La aplicación se puede ejecutar como un servicio separado al ejecutar el script usando el comando start.

Ejemplo de comando y salida de datos: 
/usr/lib/myapp/bin/myapp start
Running My Application...

Cuando se ejecuta usando el comando start, la salida de datos de la máquina JVM solo será visible si revisa el archivo wrapper.log usando tail -f wrapper.log.

Porque la aplicación es ejecutada como un proceso separado, no puede ser terminada con el comando CTRL-C, y continuará funcionando aún cuando la consola esté cerrada.

Para detener la aplicación, vuelva a ejecutar el comando stop.

Ejemplo de comando y salida de datos: 
/usr/lib/myapp/bin/myapp stop
Stopping TestWrapper Example Application...
Stopped TestWrapper Example Application.

Instalar la Aplicación para Iniciar en cada Reinicio

Introducido a partir de la versión Wrapper 3.4.0, el script de shell proporciona una manera de instalar el Wrapper como un Demonio en diferentes pçataformas (distribuciones Linux y otros sistemas Unix), permitiendo a su aplicación iniciar automáticamente en inicio o reinicio del sistema.

Ejemplo de salida de datos: 
sudo bin/testwrapper install
[sudo] password for tanuki: 
Detected Ubuntu:
 Installing service testwrapper from current directory /home/tanuki/wrapper/bin
 Adding system startup for /etc/init.d/testwrapper ...
   /etc/rc0.d/K20testwrapper -> ../init.d/testwrapper
   /etc/rc1.d/K20testwrapper -> ../init.d/testwrapper
   /etc/rc6.d/K20testwrapper -> ../init.d/testwrapper
   /etc/rc2.d/S20testwrapper -> ../init.d/testwrapper
   /etc/rc3.d/S20testwrapper -> ../init.d/testwrapper
   /etc/rc4.d/S20testwrapper -> ../init.d/testwrapper
   /etc/rc5.d/S20testwrapper -> ../init.d/testwrapper

Durante el paso de instalación, el script detectará automáticamente el sistema operativo (distribuciones Linux u otras plataformas Unix), y luego averiguará cual herramientas de gestión de servicios (como Systemd, Upstart, Initd) están presentes.. Siempre que hayan varias gestiones de servicio, se escojerá la opción más reciente y con las funciones más avanzadas. Por ejemplo, en Linux, se prefiere systemd a upstart, que por su vez se prefiere a initd. Este comportamento por defecto se introdució en la versión 3.5.31, y se puede cambiar al modificar la línea siguiente localizada en la parte superior del script: 

SERVICE_MANAGEMENT_TOOL=auto

Por ejemplo, si quiere forzar el uso de initd sobre systemd y upstart, puede usar lo siguiente: 

SERVICE_MANAGEMENT_TOOL=initd

NOTA

Note que el demonio necesita ser reinstalado para que los cambios en SERVICE_MANAGEMENT_TOOL tengan efecto.

NOTA

Conforme el script se instala solo en su OS, se necesita ejecutar los comandos install (y uninstall) como un usuario root!

Para usuarios de FreeBSD y MacOSX, o al usar Systemd or Upstart en Linux, el comando install creará un archivo de configuración por defecto que describe como la gestión de servicio del sistema operativo manejará el script durante el proceso de inicio.

Es posible personalizar este paso al guardar el archivo de configuración in el directorio bin:

  • En MacOSX, el nombre del archivo tiene que ser {nombre del archivo de su script}.plist.
  • En FreeBSD o para Upstart en Linux: {nombre del archivo de su script}.install.
  • Para Systemd: {nombre del archivo de su script}.service.

Por ejemplo, si el script se llama "testwrapper", este buscaria por "testwrapper.plist" en MacOSX, "testwrapper.install" en FreeBSD o Upstart, y "testwrapper.service" en Systemd.

Si desea desinstalar/remover el Wrapper del sistema de inicialización, ejecute el archivo (como usuario raíz!) pasando el parámetro "remove". Esto detendrá primero el Wrapper y finalmente se limpiará desde su inicialización.

Ejemplo de salida de datos: 
sudo bin/testwrapper remove
[sudo] password for tanuki: 
Stopping TestWrapper Example Application...
Stopped TestWrapper Example Application.
Detected Ubuntu:
 Removing service testwrapper from current directory /home/tanuki/wrapper/bin
 Removing any system startup links for /etc/init.d/testwrapper ...
   /etc/rc0.d/K20testwrapper
   /etc/rc1.d/K20testwrapper
   /etc/rc2.d/S20testwrapper
   /etc/rc3.d/S20testwrapper
   /etc/rc4.d/S20testwrapper
   /etc/rc5.d/S20testwrapper
   /etc/rc6.d/K20testwrapper

Instalar versiones previas a la versión 3.4.0 del Wrapper requiere instalación manual. Si su plataforma no está incluida, por favor lea las que ya fueron incluidas y haga las adaptaciones necesarias. Por favor, comparta cualquier información en la lista de correos wrapper-user@lists.sourceforge.net y nos alegraría incluir en nuestra siguiente liberación del Wrapper.

Binario Independiente

Como alternativa para usar los scripts que vienen incluidos con el Java Service Wrapper, tal vez prefiera iniciar el Wrapper directamente.

Uso del Wrapper

Si el wrapper ejecutable es lanzado sin parámetros o con "-?", la siguiente salida de datos se mostrará.

Ejemplo de salida de datos: 
Java Service Wrapper Professional Edition 64-bit {version}
  Copyright (C) 1999-{year} Tanuki Software, Ltd. All Rights Reserved.
    https://wrapper.tanukisoftware.com

Usage:
  ./wrapper <command> <configuration file> [configuration properties] [...]
  ./wrapper <configuration file> [configuration properties] [...]
     (<command> implicitly '-c')
  ./wrapper <command>
     (<configuration file> implicitly 'wrapper.conf')
  ./wrapper
     (<command> implicitly '-c' and <configuration file> 'wrapper.conf')

where <command> can be one of:
  -c  --console run as a Console application
  -h  --hostid  prints a list of HostIds which can be used to license this host.
  -v  --version print the Wrapper's Version information
  -?  --help    print this help message
  -- <args>     mark the end of Wrapper arguments.  All arguments after the
                '--' will be passed through unmodified to the java application.

<configuration file> is the wrapper.conf to use.  Name must be absolute or relative
  to the location of ./wrapper

[configuration properties] are configuration name-value pairs which override values
  in wrapper.conf.  For example:
  wrapper.debug=true

  Please note that any file references must be absolute or relative to the location
  of the Wrapper executable.

Ejecutar el Wrapper en un shell

Para ejecutar el Wrapper en un shell, especifique el comando -c, seguido del archivo wrapper.conf. La ubicación de la ruta al archivo wrapper.conf puede ser relativa o absoluta. Si se usa una ruta (path) relativa, dicha ruta siempre es relativa a la ubicación del archivo wrapper, no del directorio actual.

Ejemplo de Comando: 
/usr/lib/myapp/bin/wrapper -c ../conf/wrapper.conf

Iniciar la Aplicación como un Proceso Demonio

Para lanzar la aplicación como un proceso demonio usando la línea de comandos, por favor insiera wrapper.daemonize=TRUE después de la ruta del archivo wrapper.conf. Sin embargo, se recomienda usar el Script de Shell.

Ejemplo del Comando: 
/usr/lib/myapp/bin/wrapper -c ../conf/wrapper.conf wrapper.daemonize=TRUE

Referencia: Iniciar su Aplicación con el Wrapper

[Windows]

[Linux / Unix]

[Común]