spring

http://www.springframework.org

ÍNDICE

ÍNDICE

Spring - ¿Qué es? Spring – IoC Spring - AOP

© Reservados todos los derechos. El contenido de la presente no puede ser reproducido, ni en todo ni en parte, ni transmitido, ni registrado por ningún sistema de recuperación de información, en ninguna forma ni por ningún medio, sin el permiso previo, por escrito, de IT Deusto.

¿Qué es?

Spring - ¿Qué es?

Spring es un framework open-source, introducido y desarrollado en 2004. Las principales ideas las sugerió un arquitecto J2EE con reconocida experiencia, Rod Johnson.

El había escrito antes un libro titulado 'J2EE Develoment without using EJB' (‘Desarrollo J2EE sin usar EJB’) y había introducido el concepto de Light-weight container (contenedor ligero). Ante todo, su argumento es que mientras EJB tiene sus ventajas, no es siempre necesario y conveniente en todas las aplicaciones.

En Spring, podemos hacer uso de Java Beans para lograr cosas que antes sólo eran posibles con EJB. El mayor logro de Spring es simplificar el desarrollo y las pruebas unitarias. El framework Spring se puede usar en modo modular, permite el uso en partes y dejar los otros componentes que no son requeridos por la aplicación.

Spring - ¿Qué es? - EJB’s vs Spring

Es gestionada por el contenedorComputación distribuida

La implementación de usuarios y roles es específica al contenedor

Seguridad declarativa

Soporta varias tecnologías tales como JDBC, Hibernate, JDO, Ibatis, etc…º

Gestionada por el bean o por el contenedorPersistencia

Permite definir declarativamente el comportamiento de rollback

No permite definir declarativamente el comportamiento de rollback

Soporte para transaccionalidad declarativa

Soporta varios modelos transaccionales: JTA, Hibernate, JDO, JDBC, etc,,

No tiene soporte nativo para transacciones distribuidas

Necesita un gestor transaccional JTA

Soporta transaccionalidad distribuida

Gestión transaccional

SpringEJBCaracterística

Servicios http (propios de Spring). Se trata de exponer un servicio http mediante RMI.

Acegi Security System for Spring

http://acegisecurity.org/

Spring - ¿Qué es?

Es un framework contenedor de IoC (Inversion of Control) y AOP(Aspect Oriented Programming) ligero.

Ligero. Puede ser distribuido en un simple JAR de 1 MB. No es intrusivo. Los componentes desarrollados con Spring no dependen de clases de Spring

Inversion of Control. Técnica con el objetivo de facilitar el desacoplo. Las dependencias con los objetivos son proporcionadas de un modo pasivo. El componente no está encargado de obtener sus dependencias. Ejemplo: localización de un EJB.

Orientación a aspectos: Permite proporcionar los servicios middleware a los componentes que desarrollamos. El desarrollador sólo piensa en la lógica de negocio. Ejemplo de servicios: transaccionalidad, seguridad, auditoria, logging, etc…

Contenedor: Gestiona el ciclo de vida de los objetos y su configuración . No lo realiza de un modo tan pesado como el servidor de aplicaciones.

Framework: Spring permite desarrollar aplicaciones complejas a partir de componentes más sencillos. Spring proporciona mucha funcionalidad de infraestructura

Note: La distribución Spring viene en un fichero .jar grande y de forma alternativa como una serie de pequeños jars correspondientes a cada uno de los módulos que aparecen en la imagen superior (así puedes incluir sólo los que necesites)

Spring - ¿Qué es?

Spring - ¿Qué es?

Core Container: El “core container” proporciona la funcionalidad fundamental de Spring. Su componente principal es la 'BeanFactory', una implementación del patrón Factory. La BeanFactory aplica el patrón IOC para separar la configuración de la aplicación y otras dependencias del código de la aplicación.

Spring Context/Application Context: El “Spring context” es un archivo de configuración que proporciona información de contexto al framework Spring. El “Spring context” suministra servicios empresariales tales como JNDI access, EJB integration, e-mail, internalization, validation y scheduling functionality.

Spring AOP:(Aspect-Oriented): El módulo de “Spring AOP” integra la funcionalidad de la programación orientada a aspectos directamente en el framework Spring, a través de su sistema de gestión de configuración. En consecuencia podemos hacer que cualquier objeto gestionado por el Spring framework sea “AOP-enable”. El módulo “Spring AOP” proporciona servicios de gestión de transacción para objetos en cualquier aplicación basada en Spring. Con “Spring AOP” podemos incorporar gestión de transacción declarativa en nuestras aplicaciones sin depender de componentes EJB.

Spring - ¿Qué es?

Spring DAO: Las capas de abstracción JDBC y DAO de Spring ofrecen una jerarquía de excepciones muy descriptiva para gestionar la conexión con la base de datos, manejar excepciones y mensajes de error lanzados por diferentes proveedores de bases de datos. La jerarquía de excepciones simplifica el manejo de errores y reduce enormemente la cantidad de código que necesitamos para escribir, como por ejemplo la apertura y cierre de conexiones. Este módulo también proporciona servicios de gestión de transacción para los objetos de una aplicación Spring.

Spring ORM: El framework Spring puede integrarse con varios frameworks ORM como Toplink, JDO, Hibernate, OJB y iBatis SQL Maps.

Spring Web module: El módulo “Web context” está construido sobre el módulo “application context”, proporcionando contextos para aplicaciones web. En consecuencia, el framework Spring soporta la integración con Jakarta Struts, JSF y webworks. El módulo Web también facilita la tarea de manejar los parámetros de “multipart requests”.

Spring MVC Framework: El framework MVC es una implementación completa del patrón MVC para construir aplicaciones Web. El framework MVC es sumamente configurable a través de interfaces y contiene numerosas tecnologías de vistas incluyendo JSP, Velocity, Tiles y la generación de PDF y Archivos Excel.

12

Spring - en la capa cliente

Se integra con los frameworks open source más usados del mercado: Struts, Tapestry, Java Server Faces, WebWork.

Posibilidad de definir flujos de navegación cliente con WebFlow. Permite desarrollo de clientes ligeros con tecnología de plantillas

facilitando la maquetación de la solución al equipo de diseño gráfico. (Velocity, Freemarker).

Permite generación de documentos PDF (itext), Excel (Jakarta POI), generación dinámica de gráficos, etc..

Permite aplicar IoC a las acciones de Struts pudiendo realizar pruebas unitarias sobre la capa cliente sin necesidad de disponer de un contenedor. (Mayor cobertura y flexibilidad en las pruebas)

13

Spring - Integración con Sistemas Remotos

Posibilidad de comunicarse con EJB’s. El código de búsqueda del EJB es transparente al cliente (AOP), lo cual facilita las pruebas unitarias.

Comunicación RMI. Facilidad de exportar cualquier objeto como servidor RMI. La búsqueda de servicios RMI se realiza de manera transparente al cliente.

Comunicación con servicios Hessian y Burlap de Caucho. (Web Services ligeros).

Comunicación con Web Services via JAX-RPC.

14

Spring - Acceso a servicios enterprise

Servicio de Mail Planificación de trabajos con Quartz o Java Timer Servicio de mensajería Java (JMS) Servicio de nombres de Java (JNDI) Servicio de Autenticación y Autorización compatible con cualquier

servidor de aplicaciones o contenedor de servlets. Integración con Motores de Reglas compatibles con la

especificación JSR-94: Drools, Jess, etc.

15

Spring - Seguridad (Acegi Security)

Seguridad declarativa con la posibilidad de securizar lógica de negocio y de presentación.

Separa la seguridad del negocio (Croscutting-concern) Soporta los mecanismos estándar de autenticación: Básica, SSL,

basada en formulario. Integración con BBDD, LDAP, JAAS (Java Authentication and

Authorization Service). Permite soluciones Single Sign-On con integración con CAS Yale

(Central Authorization Server). Definición de canales seguros: Se define declarativamente el

conjunto de recursos con encriptación (SSL) no permitiendo comunicaciones no seguras automáticamente sobre los mismos.

16

Spring - Seguridad (II)

Librería de tags para securización de componentes visuales. Permite mecanismos de cacheo. Codificación de password avanzada: SHA y MD5. Propagación transparente de seguridad: Permite transferir el

contexto de seguridad entre varios servidores mediante RMI. Configuración no intrusiva. Sólo requiere la instalación de un filtro.

No es necesario la inclusión de librerías extras para el despliegue ni cambios especiales (ficheros descriptores de despliegue).

Integración con cualquier servidor de aplicaciones.

Spring - IoC

IoC – ¿Qué es?

Spring se basa en IoC. IoC es lo que nosotros conocemos como el Principio de Inyección de Dependencias, Inversion of Control" (IoC) o patrón Hollywood ("No nos llames, nosotros le llamaremos") consiste en: Un Contenedor que maneja objetos por ti.

El contenedor generalmente controla la creación de estos objetos. Por decirlo de alguna manera, el contenedor hace los “new” de las clases java para que no los realices tu.

El contenedor resuelve dependencias entre los objetos que contiene.

Nosotros no conectamos nuestros componentes y servicios juntos en el código pero describimos qué servicios necesita cada componente en un archivo de configuración. Un contenedor es responsable de enlazarlo. Este concepto es similar al de 'Declarative Management‘ (Gestión declarativa).

Spring realmente viene con dos contenedores distintos: Bean Factories - definidas por "org.springframework. beans.factory.BeanFactory" son los contenedores más simples y proporcionan soporte para la inyección de dependencias. Application Context (contextos de aplicaciones) – definidos por "org.springframework.context.Application Context" proporcionan servicios del framework para el desarrollo de aplicaciones, como la capacidad de resolver mensajes textuales desde un archivo de propiedades.

IoC – Bean Factory

BEAN FACTORY: La Bean factory es una implementación del patrón de diseño Factory y su función es crear y proporcionar beans. Como la “bean factory” reconoce muchos objetos en una aplicación, es capaz de crear una asociación entre objetos colaboradores cuando éstos son instanciados.

Estas son varias implementaciones de BeanFactory. La más útil es "org.springframework.beans.factory.xml.XmlBeanFactory". Ésta carga sus beans basándose en la definición contenida en un archivo XML. Para crear un XmlBeanFactory, pasa un InputStream al constructor. La fuente proporcionará un XML a la factory:

BeanFactory factory = new XmlBeanFactory(new FileInputStream("myBean.xml"));

Con ésta línea le decimos a la bean factory que lea la definición del bean del archivo XML. La definición del bean incluye la descripción de beans y sus propiedades. Pero la “bean factory” todavía no ha instanciado el bean. Para recuperar un bean de una 'BeanFactory', se llama al método getBean(). Cuando el método getBean() es llamado, la factory instanciará el bean y empezará a configurar las propiedades del bean usando inyección de dependencias.

myBean bean1 = (myBean)factory.getBean("myBean");

IoC – Application Context

APPLICATION CONTEXT: Mientras Bean Factory se usa para aplicaciones simples, Application Context es el contenedor más avanzado de spring. Igual que 'BeanFactory‘, puede ser usada para cargar definiciones de beans, conectar beans y proporcionar beans bajo demanda.

También proporciona:

1. Un medio para resolver mensajes de texto, incluyendo soporte para internacionalización.

2. Una forma genérica de cargar recursos de fichero.

3. Eventos para beans que se registran como listeners.

Por la funcionalidad adicional, es preferible usar 'Application Context' que BeanFactory. Sólo cuando la fuente es escasa, como en aparatos móviles, se usa 'BeanFactory‘.

IoC – Application Context

Las tres implementaciones comúnmente usadas de 'Application Context' son:

1. ClassPathXmlApplicationContext : Carga la definición del contexto de un archivo XML situado en el classpath, tratando las definiciones del contexto como recursos del classpath. El “application context” se carga del classpath de la aplicación usando el código:

ApplicationContext context = new ClassPathXmlApplicationContext("bean.xml");

1. FileSystemXmlApplicationContext : Carga la definición del contexto de un fichero XML del sistema de archivos. El “application context” se carga del sistema de archivos usando el código:

ApplicationContext context = new FileSystemXmlApplicationContext("bean.xml");

2. XmlWebApplicationContext : Carga la definición del contexto de un archivo XML situado dentro de una aplicación web. Spring es ligero tanto en tamaño como en consumo de recursos. El framework Spring entero cabe en un único archivo JAR que pesa sólo 1.7 MB. Y el consumo de procesador requerido por Spring es insignificante. Spring tampoco es intrusivo:(por ejemplo) los objetos de una aplicación Spring-enabled normalmente no dependen de las clases específicas de Spring.

IoC – Wiring with XML

Todos estos contenedores orientados a XML tienen sus beans definidos por un archivo XML extraordinariamente simple.

IoC – Injecting dependecies via setter methods

Es una técnica para rellenar los atributos de los beans basándose en la convención standar de nombrado:

Aqui estas estableciento un atributo int, pero podrías establecer cualquier primitiva o atributo String de la misma manera. Spring determinará automáticamente el tipo del atributo y lo convertirá adecuadamente.

IoC – Injecting dependecies via setter methods

Referencing Beans: Como hicimos antes, usamos el elemento <property> para establecer atributos que referencien otros beans. El subelemento <ref> nos permite hacerlo:

Inner Beans: Otra manera menos usada de enlazar referencias de beans es incrustar un elemento <bean> directamente en un elemento <property>.

IoC – Injecting dependecies via constructor

La inyección por Constructor es parecida, salvo que en este caso usarás el subelemento <constructor-arg> de <bean> para especificar los argumentos que has de pasar al constructor de un bean al instanciarlo. Una diferencia es que el <constructor-arg> no contiene el nombre del atributo que hizo el subelemento <property>.

Argumentos ambiguos del constructor:

IoC – ¿Cuál elegir, setter o constructor?

Argumentos a favor de la inyección por constructor:

La inyección por constructor genera fuertes dependencias a la hora de instanciar el bean. En pocas palabras, un bean no puede instanciarse sin haber dado todas sus dependencias. Es perfectamente válido y está listo para usar en la instanciación. Por supuesto, se supone que el constructor del bean tiene todas las dependencias del bean en su lista de parámetros.

Debido a que todas las dependencias del bean se establecen a través de su constrcutor, no hay necesidad de métodos superfluos. Esto ayuda a tener un menor número de líneas de código.

Al permitir que los atributos se establezcan sólo en el constructor, estás haciendo que esos atributos sean inalterables.

IoC – ¿Cuál elegir, setter o constructor?

Argumentos en contra de la inyección por constructor:

Si un bean tiene varias dependencias, la lista de parámetros del constructor puede ser bastante larga.

Si hay varias formas de construir un objeto válido, puede ser difícil proponer un único constructor ya que los constructores sólo varían en el número y el tipo de los parámetros.

Si un constructor admite dos o más parámetros del mismo tipo, puede ser dificil determinar para qué es cada uno.

La inyección por Constructor no es la más adecuada para la herencia. Un constructor de beans tendrá que pasar los parámetros a super() para establecer los atributos privados en el objeto padre.

Casi siempre utilizaremos el setter injection.

IoC – Autowiring

Se puede enlazar Spring a los beans automáticamente estableciendo el atributo “autowire” en cada <bean>:

Sin autowire

Con autowire

IoC – Autowiring

Hay cuatro tipos de autowiring:

byName: Trata de encontrar un bean en el contenedor cuyo nombre (o ID) es el mismo al del atributo que va a ser enlazado. Si no se encuentra, entonces el atributo permanerá sin enlazar.

byType: Trata de encontrar un único bean en el contenedor cuyo tipo coincida con el tipo del artibuto que va a ser enlazado. Si no se encuentra, entonces el atributo no será enlazado. Si se encuentrá más de uno, se lanzará una excepción org.springrframework.beans.factory.UnsatisfiedDependencyExcpetion.

Constructor: Trata de buscar una coincidencia entre uno o más beans en el contenedor con los parámetros de uno de los construtores del bean que se quiere enlazar. En el caso de beans ambiguos o constructores ambiguos, se lanzará una excepción org.springframework.beans.factory.UnsatisfiedDependencyException.

Autodetect: Trata de enlazar por constructor primero y después usando byType. La ambigüedad se maneja igual que con el enlace por constructor y byType.

IoC – Lazily-instantiating beans

El comportamiento por defecto para las implementaciones de “ApplicationContext” es pre-instanciar todos los “singleton beans” al comienzo. Pre-instanciación significa que una instancia de una implementación de “ApplicationContext” creará y configurará todos sus “singleton beans” como parte de su proceso de inicialización. Esto es generalmente algo bueno, porque significa que cualquier error en la configuración o en el entorno será descubierto inmediatamente (en vez de que transcurran horas o incluso días).

Sin embargo, hay veces en que este comportamiento no es el deseado. Si no quieres que un “singleton bean” sea pre-instanciado cuando se usa una implementación de “ApplicationContext”, puedes controlar esto de forma selectiva, marcando el bean correspondiente como “lazy-initialized”. Un lazily-initialized bean indica al IoC container si ha de instaciar o no el bean cuando se arranca el contenedor o cuando es solicitado por primera vez.

IoC – Postprocessing beans

Por el nombre se deduce que este proceso se realiza cuando salta algún tipo de evento. El evento que tige el comportamiento de este postprocessing bean es la instanciación y configuración de un bean. El BeanPostProcessor interface te ofrece dos oportunidades de alterar un bean después de que ha sido creado o enlazado:

El método postProcessBeforeInitialization() es invocado inmediatamente antes a la inicialización del bean (la llamada al afterPropertiesSet() y al custom initmethod del bean). Asimismo, el ProcessAfterInitialization() method es invocado inmediatamente después de la inicialización.

IoC – Postprocessing beans

Para registrar los Postprocessing beans en el Application Context hay dos mecanismos posibles:

De forma programática registrando cada BeanPostProcessor usando el método addBeanPostProcessor() de la Factory

Registrar el postprocessor bean en el xml de definición del contexto:

El contenedor reconocera el bean que declaremos como de tipo BeanPostProcessor y llamará a sus métodos cada vez que es instanciado.

IoC – Postprocessing the Bean Factory

Un BeanFactoryPostProcessor realiza el postprocessing en un bean factory, después que el bean factory haya cargado sus definiciones de beans pera antes de que alguno de los beans haya sido instanciado. La interfaz BeanFactoryPostProcessor es definida como sigue:

El métdo postProcessBeanFactory() es llamado por el contenedor de Spring después de que todas las definiciones de beans hayan sido cargadas pero antes de que cualquier bean sea instanciado (incluidos los BeanPostProcessor beans).

Se suelen usar sólo los predefinidos en Spring:

PropertyPlaceholderConfigurer

PropertyOverrideConfigurer

IoC – Loading property files

Lo podemos usar para internacionalización

Es muy importante que el nombre de este bean sea “messageSource” porque el ApplicationContext buscará un bean específico con ese nombre cuando se encuentre configurando el origen de los mensajes de la apliación.

Podemos acceder a los mensajes de forma programática o usando tags de spring en la jsp:


Lo podemos usar para cargar datos de configuración dependientes del entorno de ejecución

Spring - AOP

38

Introducción AOP

Con AOP se pretende dar una solución fuera del ámbito de la POO que permita implementar funcionalidad “transversal” a todas las capas.

Croscutting Concern. El objetivo es que los desarrolladores de los componentes únicamente fijen

su atención en la lógica de negocio subyacente, aislándose de servicios tales como transaccionalidad, seguridad, logging, etc…

Croscutting Concern

40

Introducción AOP

Con programación orientada a objetos las posibles soluciones para implementar estos “cross-cutting concern” (asuntos de carácter universal) pasan por la herencia y la delegación.

Con la herencia se puede llegar a una jerarquía de objetos complicada.

Con la delegación la solución es complicada y requiere de llamadas duplicadas al objeto delegado.

AOP permite definir la funcionalidad común en un único punto. Declarativamente se define cómo y dónde esta funcionalidad es aplicada sin la necesidad de modificar la clase a la que aplicas la nueva funcionalidad.

41

Terminología AOP

Aspect: Funcionalidad genérica que se está implementando. Ej: Seguridad, logging, etc…

Joinpoint: Punto de la ejecución de un programa donde un aspecto puede ser introducido.

Advice: Implementación actual de un Aspect. Pointcut: Define en qué joinpoints va a ser aplicado el advice.

Normalmente se indicará clases explícitas y un nombre de método, pero también es posible definir expresiones regulares que definen patrones para nombres de clases y nombres de métodos. Además es posible en algunos AOP frameworks definir un pointcut en tiempo de ejecución

42

Terminología AOP (II)

43

Terminología AOP (III)

Introducción: Permite añadir atributos y métodos a clases existentes. Ejemplo: Auditable advice

Target: Clase a la que se le aplica un aspecto. Proxy: Es el objeto creado después de aplicar un aspecto a un objeto

target. Weaving: Es el proceso de aplicar aspectos a objetos targets para crear

un nuevo objeto proxy. Los aspectos son “tejidos” (woven) dentro de los objetos target en los especificados joinpoints.

El proceso de “tejido” puede realizarse en los siguientes momentos: Tiempo de compilación: Requiere un compilador especial. Tiempo de carga de clase: Aspectos son tejidos cuando el objeto target es

cargado dentro de la JVM. Requiere un classloader especial que aumente el bytecode de la clase target antes de que la clase sea introducida dentro de la aplicación

Tiempo de ejecución. El contenedor AOP genera en proxy en tiempo de ejecución.

44

Implementación AOP en Spring

Los frameworks de AOP son diversos. Algunos presentan la funcionalidad de aplicar aspectos cuando se modifica el valor de un atributo, mientras que otros se quedan al nivel de invocación de métodos.

Nos centraremos en cómo Spring permite implementar AOP. Los advice de Spring están escritos en Java. Los pointcuts son definidos via XML dentro de la configuración de

Spring. Spring aplica los aspectos en tiempo de ejecución. Genera el proxy

cuando se carga el bean dentro del BeanFactory. No es necesario ningún compilador especial.

45

Implementación AOP en Spring

Genera los proxies de dos maneras: Si la clase target cumple un interfaz Spring usa la clase de la JDK

java.lang.reflect.Proxy. Si la clase target no cumple un interfaz se usa CGLIB (similar a

Hibernate para las propiedades/asociaciones perezosas). NO RECOMENDADO

No pueden aplicarse aspectos a métodos marcados como final. Spring genera una subclase de la target.

Sólo soporta joinpoints a nivel de método.

46

Advice. Tipos

47

Poincut. Tipos

Permiten definir dónde los advice son aplicados. Pointcuts determinan si un determinado método de una

determinada clase cumple con un criterio particular. Spring permite que los advice sean tejidos dentro de las clases de

la aplicación de una manera flexible.

public interface Pointcut

{

public abstract ClassFilter getClassFilter();

public abstract MethodMatcher getMethodMatcher();

}

48

Pointcut interfaces. ClassFilter y MethodMatcher

public interface ClassFilter

{

public abstract boolean matches(Class targetClass);}

public interface MethodMatcher

{

public abstract boolean matches(Method method, Class targetClass);

public abstract boolean isRuntime();

public abstract boolean matches(Method method, Class targetClass, Object args[]);

}

49

Advisor

La mayoría de aspectos son una combinación de la implementación de los mismos (advice) que define el comportamiento del aspecto y un pointcut que define donde el aspecto debería ser ejecutado.

En Spring la mayoría de pointcuts predefinidos tienen un advisor asociado PointcutAdvisor.

De esta forma la información está recogida en un único punto.

50

Pointcut estáticos

StaticMethodMatcherPointcut es la clase base para poder crear pointcuts estáticos. En el caso de necesitar implementar uno propio únicamente es necesario sobreescribir esta clase e implementar el método isMatch.

Pointcut estáticos provistos por Spring: NameMatchMethodPointcut: Permite el uso de wildcard “*”

public void setMappedName(String) public void setMappedNames(String[]) Ej: set* Todos los métodos setter

Pointcut con expresiones regulares (RegExpMethodPointcut). Permite definir expresiones regulares de tipo Perl para definir los métodos que van a ser “interceptados”.

51

Pointcut dinámicos

ControlFlowPointcut: Recoge la información de la pila de llamada del thread actual. Ejemplo podríamos interceptar la llamada de un determinado servlet mediante un MethodBeforeAdvice.

Este tipo de pointcut tiene asociada una penalización del rendimiento de la aplicación con respecto a otros pointcut dinámicos. Java1.4 cinco veces más lento. Java1.3 diez veces más lento.

ControlFlowPointcut es el único pointcut dinámico provisto por Spring. Recordar que se pueden desarrollar pointcut dinámicos implementando el interfaz MethodMatcher devolviendo “true” en el método isRuntime() del mencionado interfaz

52

Operaciones sobre pointcuts

Spring permite la union y la intersección de pointcuts ComposablePointcut.

Se pueden combinar cualquier número de pointcut, ClassFilter y MethodMatcher.

53

Introductions

Introductions son advice que afectan en el ámbito de clase, permitiendo añadir métodos y atributos nuevos en la clase.

Permite los mismos beneficios que la herencia múltiple. IntroductionMethodInterceptor es un subinterfaz de

MethodInterceptor añadiendo un método adicional: boolean implementsInterface(Class intf);

Si el método implementsInterface devuelve “true” entonces IntroductionMethodInterceptor es responsable de implementar el mencionado interfaz. Cualquier invocación de un método declarado en el interfaz será delegado al método invoke() de IntroductionMethodInterceptor

CUIDADO al llamar una clase con introduction fuera de Spring!!!

54

ProxyFactoryBean

55

Autoproxying

Cuando el número de objetos proxy es pequeño con ProxyFactorybean es suficiente. En el caso de aumentar el tamaño de objetos proxy es necesario que el contenedor los cree de manera explícita.

Tipos: BeanNameAutoProxyCreator: Mediante una expresión podemos

identificar el conjunto de beans dentro de la factoría que se quiere interceptar con un determinado advice

DefaultAdvisorAutoProxyCreator: Sólo trabaja con advisor (ya que necesita saber a qué beans debería aplicar el aspecto

Similar a un BeanPostProcessor este bean peina el contexto en la búsqueda de Advisor.

56

BeanNameAutoProxyCreator

57

DefaultAdvisorAutoProxyCreator

58

Metadata autoproxying

Es posible que el proceso de autoproxy se base en metadatos (atributos a nivel de fuente). Ejemplo: Transacción declarativa

spring

Documents