Encapsulación microservicio Spring Boot en un servicio Linux

Vamos a desplegar un microservicio Spring Boot dentro de un servicio de Linux, para permitir su ejecución de manera independiente como un proceso. Para ello, partimos de que ya tenemos el código listo en su respectivo jar (en otra entrada explicaremos como hacer esta tarea apoyándonos en nuestro IDE con Maven):

1.) Accedemos a la máquina Linux con el usuario que tendrá permisos para lanzar el servicio.

 

2.) Subimos el fichero jar a nuestra máquina Linux, a un directorio donde tengamos permisos de escritura, por ejemplo en nuestro caso /var/microservice.

 

3.) Otorgamos permiso de ejecución al fichero jar:

    chmod 500 /var/microservice/app-microservice.jar 

 

4.) Creamos un script que creará el service para la máquina Linux:

        echo '[Unit]' >> /tmp/app-monitor.service
    echo 'Description=App monitoring Microservice' >> /tmp/app-monitor.service
    echo 'After=syslog.target' >> /tmp/app-monitor.service
    echo '' >> /tmp/app-monitor.service
    echo '[Service]' >> /tmp/app-monitor.service
    echo 'User=oracle' >> /tmp/app-monitor.service
    echo 'ExecStart=/usr/lib64/jvm/jre-1.8/jre1.8.0_281/bin/java -jar      /var/microservice/app-monitoring.jar' >> /tmp/app-monitor.service
    echo 'SuccessExitStatus=143' >> /tmp/app-monitor.service
    echo 'StandardOutput=syslog' >> /tmp/app-monitor.service
    echo 'StandardError=syslog' >> /tmp/app-monitor.service
    echo 'SyslogIdentifier=app-monitor' >> /tmp/app-monitor.service
    echo '' >> /tmp/app-monitor.service
    echo '[Install]' >> /tmp/app-monitor.service
    echo 'WantedBy=multi-user.target' >> /tmp/app-monitor.service   

 

Viendo un poco el script en detalle, los puntos importantes son que creará un fichero service llamado app-monitor que dejará en la carpeta /tmp, y la línea de ejecucción del servicio usa la jre 1.8 ya que es la mínima necesaria para ejecutar Spring Boot y apunta a la ruta donde hemos dejado nuestro fichero jar. 

 

5.) Ejecutamos el script, que creará el fichero app-monitor.service en la carpeta /tmp.

 

6.) Copiamos el service a la ruta /etc/systemd/system, que es donde residen los servicios de nuestro servidor Linux.

 

7.) A partir de aquí manejaremos el servicio como otro cualquiera de Linux, apoyándonos en el comando systemctl.

     

    a) Habilitar el servicio => sudo systemctl enable app-monitor.service

    b) Arrancar/Parar el servicio => sudo systemctl start/stop app-monitor.service

    c) Estado/log => sudo systemctl -l status app-monitor.service

 

   

 

 

jQuery en ADF

Ejemplo práctico de como usar jQuery en ADF, en este caso como cambiar el type de un inputText para el caso de querer mostrar los caracteres de un campo contraseña.

<af:resource type="javascript"
                     source="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"/>
        <af:resource type="javascript">

          function showPasswordMethod(e) {
              var inputPassword1 = $("input[id*=it2]")[0];
              if (inputPassword1.type == "text") {
                  inputPassword1.type = "password";
                  $("img[id*=imgShowPassword]")[0].src = "/webcenter/../wcstatic/img/genericas/eye_black.png";
              }
              else {
                  inputPassword1.type = "text";
                  $("img[id*=imgShowPassword]")[0].src = "/webcenter/../wcstatic/img/genericas/eye_red.png";
              }
          }
        </af:resource>

<af:inputText label="Contraseña actual" id="it2" required="true"                                     styleClass="resetPasswordField oldpwd" value="#{resetPasswordBean.oldpassword}"
 secret="true" autoComplete="off"/>
<af:image source="/../wcstatic/img/genericas/eye_black.png"                                  id="imgShowPassword" inlineStyle="position: absolute;bottom: 190px; right: 14px; cursor: pointer;">
      <af:clientListener method="showPasswordMethod" type="click"/>
</af:image>

Atributo ClearCacheOnCommit en ADF

En un desarrollo reciente disponemos de una tabla ADF con varios registros, basado en un VO Entity updatable en donde se puede operar con acciones CreateInsert y Delete, con su posterior Commit, cada row con un atributo PK independiente.

Nos surgió la problemática de que, sin salir de la taskflow, al realizar el CreateInsert y a continuación realizar el Delete de esa misma row (con las opciones out of the box de binding mediante getCurrent) veíamos como se borraba de la tabla pero no de base de datos.

¿Cual era el problema? Para explicarlo mostramos el ciclo de vida de ADF:

 

Cuando se realiza la operación CreateInsert, se inserta y accede al binding correspondiente, se accede al AppModule y se inserta en base de datos, pero no se actualiza el datacontrol con dicha información, es decir, se inserta la row en el iterator pero no ha refrescado con la PK que ha devuelto la base de datos, por lo que la row insertada y que se ve en la tabla no tiene actualizado el campo PK devuelto por el modelo.
Como se puede deducir, si no refrescas el iterator o pides de nuevo los datos a la base de datos, esa row no se actualiza con su verdadero PK por lo que al borrar inmediatamente después lo va a borrar del iterator pero no de base de datos.

La solución consiste en usar el atributo ClearCacheOnCommit en el fichero AppModule de nuestra aplicación:

Dicho atributo permite refrescar los VO después de realizar la operación Commit, por lo que siempre vamos a tener en este caso deseablemente el valor introducido en base de datos.
Si no se refleja esta variable en el AppModule, por defecto no aparecerá y tomará el valor "false", como se indica en la documentación (esto es del método isClearCacheOnCommit de la interfaz Transaction para consultar dicho valor):

isClearCacheOnCommit

public boolean isClearCacheOnCommit()

Returns the flag indicating whether all Entity Object caches will be cleared after the transaction is committed.After the transaction is committed, the value of this flag is used to determine whether the Entity Object caches are cleared or not. If this flag value is false, the cache contents are kept. In this case, the cache may contain data that is stale in that it does not match the newest data (changes made by another user and committed).
If this flag is true, the caches are cleared after the transaction is committed. When the user brings in data by traversing row collection, the latest data from the database will be brought into Entity caches.

Returns:

the current value of clear-cache-on-commit flag.

See Also:

RowSet.executeQuery(), setClearCacheOnCommit(boolean val)

Importar y configurar un proyecto Maven en Eclipse

Cuando vamos a trabajar con un proyecto Maven que tenemos en nuestro SVN y lo vamos a configurar en nuestro entorno de desarrollo, necesitamos realizar los siguientes pasos:

1º) Hacemos checkout del SVN del proyecto, y con el asistente lo descargamos como proyecto Java.

 

 

2º) Debemos seleccionar la opción "Import" del menú "File", para a continuación importar el proyecto como Maven.

 

3º) Por último, seleccionamos la opción de convertir a Proyecto Maven, haciendo click derecho en el proyecto.