Por defecto, los Servicios de Windows son ejecutados como Usuario SISTEMA (SYSTEM user). El problema es que el usuario SISTEMA no tiene acceso a la Red de Recursos (Network Resources). Si su aplicación está trabajando bien cuando es ejecutada como un Servicio de Windows, lo primero es tratar de ejecutar su servicio como el usuario que estaba conectado cuando la aplicación era ejecutada como una aplicación de consola.

Procedimiento:

• Primero desinstale su aplicación si está instalada como un Servicio de Windows.
• Edite el archivo wrapper.conf estableciendo las propiedades wrapper.ntservice.account y wrapper.ntservice.password.
• El siguiente paso es reinstalar e iniciar su servicio.

El servicio ahora se ejecutará en el mismo entorno que en el que estaba siendo ejecutado como una aplicación de consola, y ahora todo debe funcionar correctamente.

Dependiendo de sus requisitos de seguridad, puede optar por crear y configurar un nuevo usuario especialmente para este servicio.

En algunos sistemas, unidades asignadas a una letra de unidad (alfabeto indicando una unidad) no son siempre accesibles al iniciar el sistema, hasta que un usuario real inicie sesión y se conecte a la unidad. Para solucionar esto, se usa el sintaxis "UNC sintax" (ruta completa incluyendo el nombre de la máquina) para hacer referencia de la unidad directamente, en lugar de asignar una letra a dicha unidad.

//host/share/path

Cuando se solicita la ejecución de un vertedero de memoria al presionar CTRL-BREAK, CTRL-\ o a través de una API, se obtiene el siguiente mensaje en el archivo de registro y la máquina JVM es reiniciada:

wrapper  | JVM exited unexpectedly.

Asegúrese de no haber especificado la bandera -Xrs al lanzar la máquina JVM. Dicha bandera es de gran ayuda en algunos entornos cuando se usa Java sin el Wrapper, pero esto compromete la habilidad del Wrapper para responder a las varias señales del sistema.

Para decirle al Wrapper y que su máquina JVM ignore estas señales del sistema, use la propiedad wrapper.ignore_signals. Por favor asegúrese de haber leído el documento primero.

Algunos usuarios han reportado problemas al intentar que sus aplicaciones COM funcionen con el Wrapper. Una aplicación COM funcionará bien al ejecutarse de una manera independientemente (standalone application), pero al ser ejecutada con el Wrapper, errores como el siguiente serán generados:

Caught java.lang.NullPointerException: name can't be null while loading driver com.sun.comm.Win32Driver

Una API de una aplicación necesita que esten disponibles dos archivos: El archivo win32com.dll en la ruta de la librería y un archivo javax.comm.properties ubicado en un subdirectorio lib del directorio regresado por System.getProperty("java.home"). The COM API requires two files to be available. The win32com.dll file on the library path, and a javax.comm.properties file located in a lib subdirectory of the directory returned by System.getProperty("java.home").

Algunos problemas son causados si su archivo wrapper.conf ha configurado que use una máquina JVM diferente de la especificada por sy variable de entorno JAVA_HOME. Puede asegurarse que está usando la máquina JVM correcta al especificar la propiedad wrapper.java.command en su archivo wrapper.conf.

wrapper.java.command=%JAVA_HOME%/bin/java

La única diferencia entre la forma en que su aplicación se está ejecutando bajo el Wrapper y la forma en la que se estaba ejecutando antes de integrarse es que antes el método principal de su aplicación estaba siendo llamado directamente por la máquina JVM al iniciar. Ahora, asumiendo que está usando las clases de ayuda WrapperSimpleApp o WrapperStartStopApp, la máquina JVM primero llama al método principal de la clase, y después que se inicia el Wrapper, llama al método principal de la aplicación.

a> Esto puede causar algunos problemas cuando se está usando un Administrador de Seguridad. La razón es que el Administrador de Seguridad Java busca una pila de llamadas para asegurarse que cada clase y método sean autorizados para llamar el código protegido antes de conceder acceso. Si las clases del Wrapper existen en su estructura de datos y no se les da privilegios, entonces recibirá una excepción de seguridad.

Intente conceder permisos a wrapper.jar al agregar lo siguiente. Normalmente resuelve este tipo de problemas.

// Give Wrapper classes full permissions
grant codeBase "file:../lib/wrapper.jar" {
    permission java.security.AllPermission;
};

Algunas aplicaciones Java Service tienen un problema con el proceso de salida Java cuando un usuario cierra sesión en Windows. El Wrapper ha manejado esto correctamente desde su primera liberación.

El lado Java del Wrapper requiere una biblioteca nativa (Windows: wrapper.dll, libwrapper.so) para que funcione. La biblioteca nativa es responsable de detectar todas las señales del sistema enviadas al proceso de la máquina JVM y manejarlas correctamente. Una Aplicación Java puede manejar estas señales al implementar el método controlEvent en la interfazWrapperListener.

Si experimenta problemas con su máquina JVM al ser reiniciada con el Wrapper cuando un usuario cierra sesión, por favor verifique que la biblioteca está siendo cargada. Si no es así, entonces un mensaje de advertencia será mostrado en la salida de datos de la máquina JVM al iniciar WrapperManager.

Puede encontrar ejemplos de lo que pasa cuando un usuario cierra sesión mientras el Wrapper está siendo usado para ejecutar una aplicación de consola como un servicio en la sección de ejemplos de la documentación.

En sistemas Windows, la prioridad puede ser configurada al hacer uso de la propiedad wrapper.ntservice.process_priority en el archivo wrapper.conf. Para más detalles, por favor visite Descripción de Configuraciones.

En sistemas UNIX, el método sugerido para configurar la prioridad es usar el comando "nice" en sus shell scripts al lanzar el Wrapper. El ejemplo de dichos scripts incluidos con el Wrapper le muestran como hacerlo. Visite "man nice" o "info nice" para detalles sobre como usar "nice".

Por defecto, el Wrapper configura el directorio de usuario de las máquinas JVM ubicándolas ya sea en el archivo wrapper.exe en Windows o en el shell script del Wrapper en sistemas UNIX. Esto se hace para hacer uso de rutas relativas dentro de su aplicación de forma fiable. Normalmente esto no sería posible porque el directorio del usuario dependería del lugar de donde la máquina JVM fue lanzada.

Rutas relativas hacen que la instalación de una aplicación sea sin complicaciones, ya que normalmente pueden ser extraídas (unzipped) en un directorio y ejecutadas con fiabilidad.

Hay algunos casos en que es necesario configurar el directorio del usuario a una ubicación otra a la predeterminada. Esto se hace al configurar la propiedad wrapper.working.dir.

Cuando se ejecutan varias copias del Wrapper en Windows, no es fácil identificar cual aplicación es cual en el Administrador de Tareas porque todas aparecerán como wrapper.exe y java.exe. No le es posible al Wrapper implementar una función para cambiar el nombre, ya que Windows no lo permite por razones de seguridad.

Resolver esto puede ser un poco difícil, pero funciona muy bien.

• Cambie el nombre del archivo de wrapper.exe a wrapper-myapp.exe.
• Después, modifique los archivos batch para que usen el nuevo wrapper-myapp.exe.
• Para el proceso Java, usted tiene que hacer lo mismo. Visite el directorio %JAVA_HOME%/bin y simplemente copie java.exe a java-myapp.exe.
• Después modifique el archivo wrapper.conf para que se use el nuevo java-myapp.exe.

Ahora cuando vea su Administrador de Tareas de Windows, será fácil de identificar cual exe es cual.

Note que también puede configurar las propiedades wrapper.pidfile y wrapper.java.pidfile en el archivo wrapper.conf. Estas propiedades crearán archivos conteniendo los protocolos de sistema de detección de intrusos (PIDS). Estes pids pueden ser comparados con los que se muestran en el Administrador de Tareas. Tenga en mente que necesita configurar el Administrador de Tareas para mostrar los pids de procesos.

En Windows, se hace al configurar la propiedad RUN_AS_USER en el shell script del Wrapper src/bin/App.sh.in (en versiones anteriores del Wrapper, este archivo se llamaba 'sh.script.in'). Asegúrese de leer la documentación en su totalidad y entonces reinstale el servicio.

En UNIX, se configura la variable RUN_AS_USER en el shell script del Wrapper src/bin/App.sh.in. Cuando se ejecuta con el comando console, el Wrapper se ejecutará como el usuario actual. Sin embargo, cuando ejecutado con el comando start, este cambiará al usuario especifico y después lanzará el Wrapper. Esto significa que el usuario actual necesita tener permiso para cambiar de usuarios.

Si una aplicación Java está siendo ejecutada como un Servicio de Windows, en realidad no esá siendo ejecutada en el mismo contexto/sesión como si el usuario estuviera lanzando una interfaz VisualVM. Por lo tanto, por defecto VisualVM no puede encontrar la aplicación Java.

Hasta Windows XP, las políticas de seguridad laxas para Servicios de Windows hicieron posible resolver esto fácilmente con los siguientes pasos:

En el momento que la máquina JVM inicia, también está escribiendo sus procesos y la información del hook a la ubicación especificada por la variable de entorno %TMP%. Tenga en mente que algunas variables de entorno (incluyendo esta) son definidas diferentes para cada usuario. Por lo tanto, los dos procesos su aplicación&VisualVM necesitan sincronizar esta variable de entorno.

set.TMP=C:\tmp

Después de hacerlo, (re)inicie el servicio. Ahora inicie la consola y configure la variable de entorno TMP con el mismo valor que usted ha establecido en el archivo de configuraciones:

set TMP=C:\tmp
C:\Program Files\...\jvisualvm.exe

La interfaz VisualVM debe estar habilitada ahora para para listar el proceso Java.

Mientras que la configuración previa funciona con versiones de Windows hasta Windows XP, y a partir de Windows Vista/7 en adelante, lo más probable es que ya no lo permitan por medidas de seguridad más estrictas. Así que la única manera de resolver esto es usando las configuraciones de Monitoreo Remoto del JMX (esto requiere por lo menos Java 1.5).

wrapper.java.additional.N=-Dcom.sun.management.jmxremote.port=XXXX
wrapper.java.additional.N=-Dcom.sun.management.jmxremote.ssl=false
wrapper.java.additional.N=-Dcom.sun.management.jmxremote.authenticate=false

Por favor use números que no han sido usados para 'N' con la propiedad wrapper.java.additional.<n> y reemplace 'XXXX' con un número de puerto que no ha sido usado en su máquina. Desde VisualVM, por favor seleccione "File"-> "Add JMX Connection". En el campo "Connection", por favor introduzca "localhost:XXXX" (XXXX es el puerto que usted ha asignado en el archivo conf).

En algunos entornos donde máquinas virtuales son borradas y creadas constantemente con herramientas de automación, el Wrapper dejará de funcionar así que el HostId (que es basado en la dirección MAC) sea diferente del especificado en la clave de licencia. En ese caso, el dueño de la licencia debe restablecer manualmente la clave de licencia, lo que quiebra el proceso de creación de máquinas virtuales. Dependiendo de la herramienta de virtualización que esté usando, es posible configurar una dirección MAC fija a máquinas virtuales. Haciendo con que se use siempre la misma dirección MAC le garantirá que el Wrapper siempre iniciará sin errores con la clave de licencia.

Por favor consulte la siguiente documentación:

• VMware
• VirtualBox
• AWS