Frameworks·Java·Programación·Spring

Gestión de excepciones en Spring MVC

Spring MVC proporciona varias formas de gestionar el manejo de excepciones. Vamos a repasar dichas opciones teniendo en cuenta que nuestro objetivo es no gestionar las excepciones de forma explícita en mos métodos de los controladores siempre que sea posible.

Existen tres opciones: por excepción, por controlador o globalmente.

Spring Boot

Spring Boot permite tener un proyecto Spring con una configuración mínima y seguramente será lo que utilices en tu aplicación si ésta no tiene unos cuantos años.

Spring MVC no ofrece por defecto una página de error (fall-back). El modo más común de establecer dicha página de error por defecto siempre ha sido el SimpleMappingExceptionResolver.

Sin embargo, Spring Boot, sí que proporciona una página.

Al arrancar la aplicación, Spring Boot intenta encontrar un mapeo para /error. Por convenio, una URL que termina en /error se mapea con una vista lógica del mismo nombre: error. El mapeo real dependerá del ViewResolver (si hay alguno) que haya en la configuración de Spring Boot.

Si no se encuentra ningún mapeo para /error, Spring Boot define el suyo propio, la llamada “Whitelabel Error Page” (una página mínima con información del estado HTTP y detalles del error, tales como el mensaje de la excepción no capturada).

Si estás realizando una petición RESTful (la petición HTTP especifica una respuesta de otro tipo distingo a HTML), Spring Boot devuelve una representación JSON de la misma información que pone en la “Whitelabel Error Page”.

Spring Boot también establece una página de error por defecto para el contenedor, equivalente a la directiva <error-page> de web.xml (aunque implementada de forma muy diferente). Así, las excepciones lanzadas fuera del framework Spring MVC, tales como las de los filtros de servlet, también son reportadas por la página de error de Spring Boot.

Sigue leyendo “Gestión de excepciones en Spring MVC”
Recetas·Ubuntu·VSCode

Usando vscode-chrome-debug como extensión de workspace

Visual_Studio_code_logo-274x300

Escenario:

  • VSCode con las extensiones de Remote Development instaladas.
  • Desarrollo en contenedores Docker.
  • Imagen Docker con chrome instalado.
  • Chrome no instalado en la máquina host.
  • Queremos utilizar el chrome del contenedor Docker para depurar nuestras aplicaciones.

Guía paso a paso:

  • Utilizar un Dockerfile basado en una imagen con chrome instalado (en mi caso, utilizo una imagen basada en Ubuntu 18.04 y personalizada para mis necesidades de desarrollo)

    FROM rubensa/ubuntu-tini-dev-chrome
    # Keep container running (for use in VSCode)
    CMD [ “tail”, “-f”, “/dev/null” ]
  • En el fichero devcontainer.json añadir la extensión Debugger for Chrome y forzarla para se se ejecute en “workspace” (en vez de en “ui“)
    {
      ...
      "extensions": [
        // Chrome debugger
        "msjsdiag.debugger-for-chrome"
      ],
      "settings": {
        "remote.extensionKind": {
          // Force chrome debugger extension installation on container
          "msjsdiag.debugger-for-chrome": [
            "workspace"
          ]
        }
      },
      ...
    }

    NOTA: para que esto funciona, también es necesario instalar la extensión localmente (pero manteniéndola deshabilitada Locally y habilitada en Dev Container)

  • Configurar los siguientes argumentos Docker dentro del fichero devcontainer.json
    {
      ...
      "runArgs": [
        // X11 Unix-domain socket
        "--mount",
        "type=bind,source=/tmp/.X11-unix,target=/tmp/.X11-unix",
        "--env=DISPLAY=unix${localEnv:DISPLAY}",
        // Allow shared memory to avoid RAM access failures and rendering glitches due to X extesnion MIT-SHM
        "--ipc=host",
        // The kernel requires SYS_ADMIN for Chrome sand-box
        "--cap-add",
        "SYS_ADMIN",
        // $(id -u):$(id -g)
        "-u",
        "1000:1000"
      ],
      ...
    }
    

    En mi Dockerfile particular debo especificar en devcontainer.json que VSCode no sobreescriba el comando por defecto de mi imagen.

    {
      ...
      "overrideCommand": false
      ...
    }
    

Ahora, al abrir tu proyecto en Remote – Containers, podrás depurar el código dentro del contenedor.

Recetas·VSCode

VSCode Live Share login manual

vscode-liveshare-logo

  • Haz login usando cualquier cuenta en la página: https://prod.liveshare.vsengsaas.visualstudio.com/auth/login
    Screenshot from 2020-02-19 16-54-21
  • Tras el flujo de autentificación se te redirecciona a la página “Ready to collaborate
    Screenshot from 2020-02-19 16-55-38
  • Pulsa en el enlace “Having trouble? Click here for user code directions
    Screenshot from 2020-02-19 16-56-26
  • Abre la paleta de comandos del VSCode y escribe > live share: Sign in with user code
    Screenshot from 2020-02-19 17-00-47
  • Pega el código de usuario que has copiado del navegador.

NOTA: El código de usuario solamente es válido durante 2 minutos (comenzando desde que se te muestra la página “Ready to collaborate”)

Angular·Ubuntu

Port forwarding en VSCode Remote Development

remote-extensionpack

Trabajando en un proyecto en Angular usando la extensión de desarrollo remoto que VSCode tiene para poder desarrollar dentro de un contenedor Docker, me encontré con un extraño comportamiento:

Al arrancar el servidor de desarrollo de Angular mediante ng serve, en la consola del VSCode se me mostraba el típico mensaje con el enlace para abrir la aplicación en el navegador.

** Angular Live Development Server is listening on localhost:4200, open your browser on http://localhost:4200/ **

Lo curioso del caso es que al pulsar (Ctrl+Click) en dicho enlace se me habría el navegador en la URL http://127.0.0.1:40999/ en vez de http://localhost:4200/.  Es más, si intentaba acceder a http://localhost:4200/ no podía acceder a la aplicación. 

Y todo esto, habiendo publicado el puerto en el fichero devcontainer.json


...
"appPort": [
// Front-end development (Angular server)
"0.0.0.0:4200:4200"
],
...

Sigue leyendo “Port forwarding en VSCode Remote Development”

Programación·Recetas·Ubuntu

Spring Boot live application information en VSCode

spring-bool-live-application-information-en-vscode

En las últimas versiones de Spring Boot, el soporte JMX no está habilitado por defecto.  Para habilitarlo, es necesario arrancar la aplicación con algo como esto:

java -Dspring.jmx.enabled=true -Dspring.application.admin.enabled=true -jar target/spring-petclinic-2.2.0.BUILD-SNAPSHOT.jar

En VSCode, la extensión al arrancar la aplicación usando el SPRING-BOOT DASHBOARD ya se establece a true la propiedad spring.application.admin.enabled pero no ocurre lo mismo con spring.jmx.enabled.

Para conseguirlo tenemos que abrir el fichero .vscode/launch.json y añadir el parámetro de configuración vmArgs con dicho valor:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "type": "java",
            "name": "Debug (Launch)-PetClinicApplication",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "console": "internalConsole",
            "stopOnEntry": false,
            "mainClass": "org.springframework.samples.petclinic.PetClinicApplication",
            "projectName": "spring-petclinic",
            "args": "",
            "vmArgs": "-Dspring.jmx.enabled=true"
        },
        {
            "type": "java",
            "name": "Debug (Attach)",
            "request": "attach",
            "hostName": "localhost",
            "port": 0
        }
    ]
}

Además, en el spring-boot tooling, el language server ya no se auto conecta con la mayoría de procesos (una excepción son las aplicaciones lanzadas por el Boot Dashboard de Eclipse).  Esto lo tienes que hacer explícitamente en VSCode del siguiente modo:

  1. Pulsa CTRL-SHIFT-P
  2. Escribe ‘live
  3. Selecciona el comando ‘Manage Live Boot Process Connections
  4. Selecciona el proceso de tu aplicación y conéctate al mismo.

vía

node

¿Pero qué demonios es package-lock.json?

nodejs

package-lock.json es un fichero muy importante que te evitará un montón de problemas en tus repositorios.

Pero antes de entrar en la discusión acerca de package-lock.json vamos a hablar un poco acerca de el versionado semántico y package.json. Sigue leyendo “¿Pero qué demonios es package-lock.json?”

Java

Eclipse MicroProfile

Historia

mp-logo-w-tagline

  • 2016
    El 27 de Junio de 2016, durante una key note de la DevNation, Red Hat, IBM, Payara, Tomitribe y London Java Community anunciaron un Micro Profile para Java EE con el objetivo de optimizar las arquitecturas Java EE para microservicios.
    Se trataría de un nuevo Profile (introducidos en Java EE 6) no oficial.
    El 19 de Septiembre, durante la JavaOne 2016, se anunció la primera versión oficial.
    El 14 de Diciembre se anuncia que oficialmente MicroProfile se convierte en Eclipse MicroProfile.
  • 2017
    El 8 de Agosto de 2017 se anunció en el hangout público de Eclipse MicroProfile la nueva versión MicroProfile 1.1, una nueva revisión que únicamente añadía una nueva especificación, la Config API. Esta especificación proporciona la capacidad de configurar la aplicación para diferentes estados/entornos del ciclo de vida de desarrollo software (Software Development Lifecycle SDLC) sin tener que re-empaquetar y re-construir la aplicación.
    El 3 de Septiembre de 2017 se anuncia la disponibilidad de MicroProfile 1.2, que actualiza el Config API y añade Health Check, Fault Tolerance, Metrics y JWT Authentication API.
    En Noviembre de 2017, Oracle se suma como miembro de la organización que soporta la iniciativa Eclipse MicroProfile.
  • 2018
    El 3 de Enero de 2018 se anuncia la disponibilidad de Eclipse MicroProfile 1.3 que actualiza alguna versión de las APIs existentes y añade las de OpenAPI (para la generación automática de API para los microservicios), OpenTracing (que permite trazar las peticiones en una arquitectura de servicios distribuidos) y Rest Client (un modo consistente de invocar a los servicios).
    El 28 de Junio se anuncia la disponibilidad de Eclipse MicroProfile 1.4 y 2.0. La versión 1.4 se anuncia como la última compatible a nivel de versiones con Java EE7 mientras que la 2.0 se alinea con las versiones de la especificación Java EE 8 y añade el API JSON-B.
    El 19 de Octubre se anuncia MicroProfile 2.1 que trae como única novedad la revisión 1.2 del API Open Tracing.

Sigue leyendo “Eclipse MicroProfile”

Java

Principales características de las versiones de JavaEE

java-ee.png

Versión Fecha de Lanzamiento
JPE Anuncio en Mayo de 1998
J2EE 1.2 12 Diciembre 1999
J2EE 1.3 24 Septiembre 2001
J2EE 1.4 11 Noviembre 2003
Java EE 5 11 Mayo 2006
Java EE 6 10 Diciembre 2009
Java EE 7 28 Mayo 2013
Java EE 8 31 Agosto 2017

Sigue leyendo “Principales características de las versiones de JavaEE”

Java

Principales características de las versiones de Java

java_versions

Versión Fecha de lanzamiento Fin de Actualizaciones Públicas Gratuitas Fin de Soporte Extendido
JDK Beta 1995
JDK 1.0 Enero 1996
JDK 1.1 Febrero 1997
J2SE 1.2 Diciembre 1998
J2SE 1.3 Mayo 2000
J2SE 1.4 Febrero 2002 Octubre 2008 Febrero 2013
J2SE 5.0 Septiembre 2004 Noviembre 2009 Abril 2015
Java SE 6 Diciembre 2006 Abril 2013 Diciembre 2018
Java SE 7 Julio 2011 Abril 2015 Julio 2022
Java SE 8 (LTS) Marzo 2014 Enero 2019 para Oracle (comercial)
Diciembre 2020 para Oracle (no-comercial)
Al menos hasta Septiembre 2023 para AdoptOpenJDK
Marzo 2025
Java SE 9 Septiembre 2017 Marzo 2018
Java SE 10 (18.3) Marzo 2018 Septiembre 2018
Java SE 11 (18.9 LTS) Septiembre 2018 Al menos hasta Septiembre de 2022 para AdoptOpenJDK
Java SE 12 (19.3) Marzo 2019 Septiembre 2019 para OpenJDK

Sigue leyendo “Principales características de las versiones de Java”

Java

De Java Web Start a…

javawebstart

Introducción

Con la llegada de Java 11, Oracle ha decidido eliminar todas las partes viejas y marcadas como obsoletas (deprecated) de la JRE. Desde el punto de vista de las aplicaciones de escritorio estas son las partes relevantes que se eliminan:

  • Java Applets
  • Java Web Start
  • JavaFX

Sigue leyendo “De Java Web Start a…”