spring

http://www.springframework.org

Í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.

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.

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

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…

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

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.

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!!!

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.

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a spring

Similar a spring (20)

spring

Notas del editor