interfaz - que es awt y swing en java

¿Qué es ese ciclo de vida de clase de aplicación de un servicio de descanso?

Question

Hola chicos, soy nuevo para descansar y jax-rs, así que mi pregunta es: el servicio de descanso comienza con la ampliación de esa clase de aplicación y la definición de la ruta de acceso. Ahora mi pregunta es ¿cuál es la vida útil de esa clase de aplicación en sí? Aquí hay un ejemplo:

import javax.ws.rs.core.Application;
@javax.ws.rs.ApplicationPath("resources")
public class ApplicationConfig extends Application {}

¿Es esto un servlet? ¿Está siempre vivo? ¿Cómo voy a entender esta clase? ¿Es un frijol cdi? ¿El servidor crea esta clase en cada solicitud?

Answer 1

¿Qué es la Application ?

Application es una clase abstracta agnóstica de despliegue proporcionada por JAX-RS para configurar y registrar los componentes de una aplicación JAX-RS y también se utiliza para suministrar metadatos adicionales a la aplicación.

Application es uno de los tipos que se puede inyectar utilizando la anotación @Context . Para más detalles, consulte esta respuesta .

Subclases de Application

Application subclases de Application pueden implementar métodos como getClasses() , getSingletons() y getProperties() para configurar y registrar componentes y propiedades.

Application subclases de Application se pueden anotar con @ApplicationPath , definiendo el URI base para las clases de recursos JAX-RS (clases anotadas con @Path ). Application subclases de Application se crean una vez una vez que se inicia la aplicación web y son administradas por el tiempo de ejecución de JAX-RS.

La implementación más simple posible es la siguiente:

@ApplicationPath("api")
public SampleApplication extends Application {

}

En el ejemplo anterior, no se registran clases de recursos ni proveedores, por lo que el tiempo de ejecución de JAX-RS escaneará la ruta de clase para los componentes JAX-RS y los registrará automáticamente.

Sin embargo, de acuerdo con este post de Jakub Podlesak , este enfoque se desaconseja en los entornos de producción:

El ejemplo anterior funciona genial. Cuando se inicia, la aplicación solo escanea la ruta de clase real y agrega cada clase de componente JAX-RS que se encuentra allí a la configuración de tiempo de ejecución real. ¿No es genial? Francamente, este tipo de configuración podría funcionar bien. Hasta que alguien cambie la configuración del sistema (ruta de clase del sistema) o la forma en que se está empaquetando la aplicación (un nuevo componente de terceros podría agregarse / eliminarse de la ruta de clase de la aplicación). Estos cambios podrían estar fuera de su control y si uno de ellos sucede, la configuración de la aplicación podría romperse. Por esta razón, no es aconsejable utilizar este tipo de configuración en un entorno de producción.

Jersey, la implementación de referencia JAX-RS, proporciona la clase ResourceConfig . Comparado con la Application , ResourceConfig proporciona capacidades avanzadas para simplificar el registro de componentes JAX-RS, como la exploración de recursos raíz y clases de proveedores en un classpath proporcionado o en un conjunto de nombres de paquetes, etc. Para obtener más detalles, consulte la documentación de Jersey .

Trabajando con múltiples subclases de Application

También vale la pena mencionar que no está restringido a una única subclase de Application por aplicación web. El mismo WAR puede tener múltiples subclases de Application . Para más detalles, eche un vistazo a esta publicación de Adam Bien :

Para implementar múltiples aplicaciones JAX-RS con diferentes URI en un WAR, deberá crear una subclase javax.ws.rs.core.Application cada aplicación (o usar web.xml para este fin). Obviamente, en la omnipresente Convención sobre Configuración de Java EE (o Configuración por Excepción) no puede funcionar más: tendrá que configurar explícitamente los recursos en cada subclase anulando el método getClasses o getSingletons :

@Path("first")
public class FirstResource {

    @GET
    public String first() {
        return "first";
    }
}

@ApplicationPath("one")
public class JAXRSConfigurationOne extends Application {

    @Override
    public Set<Class<?>> getClasses() {
        Set<Class<?>> resources = new HashSet<>();
        resources.add(FirstResource.class);
        return resources;
    }
}

@Path("second")
public class SecondResource {

    @GET
    public String first() {
        return "second";
    }
}

@ApplicationPath("two")
public class JAXRSConfigurationTwo extends Application {

    @Override
    public Set<Class<?>> getClasses() {
        Set<Class<?>> resources = new HashSet<>();
        resources.add(SecondResource.class);
        return resources;
    }
}

Ambas aplicaciones JAX-RS son accesibles a través de distintos URI: http://localhost:8080/multiple-roots/one/first y http://localhost:8080/multiple-roots/two/second

¿Qué ocurre si no hay una subclase de Application presente?

Si no hay una subclase de Application presente, las implementaciones JAX-RS deben agregar un servlet y establecer su nombre en javax.ws.rs.core.Application y descubrir automáticamente todas las clases de recursos y proveedores que deben estar empaquetados con la aplicación.

Para más detalles, eche un vistazo al capítulo 2 de la especificación JAX-RS 2.0 .