spring LTW agent方式在tomcat 8下无效

在常规的spring ltw中,我们对tomcat使用ltw,一般是以下两种方式。

//1 在启动项中添加javaagent选项
-javaagent:e:/spring-instrument-4.1.1.RELEASE.jar

//2 使用自定义的启动器,在META-INF/context.xml中增加以下内容
<?xml version="1.0" encoding="UTF-8" ?>
<Context>
 <Loader loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader" /> 
</Context>

这两种方式在tomcat6以及tomcat7均可以正常工作。但对于tomcat8,第1种方式已经不能再工作,仅能使用第二种方式。原因就在于tomcat8的webClassLoader已经提供了InstrumentableClassLoader接口。此接口将导致spring直接将aspectj的AspectJClassBypassingClassFileTransformer 直接添加到tomcat的classLoader中。但由于不是很正确的实现方式,导致aspect在使用tomcat8提供的classLoader时,并不能有效地对自己的advice进行weaver,导致报以下的错误信息: 

java.lang.NoSuchMethodError: XXXAdvice.aspectOf()LXXXAdvice;
 atXXX.index(AbcController.java:30)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at org.springframework.web.method.support.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:215)
 at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:132)
 at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104)

这个错误的产生在于aspectJ的初始化过程和classLoader之间的交互行为,以及tomcat8中不准确的缓存行为。

继续阅读“spring LTW agent方式在tomcat 8下无效”

aspectj中call和execute在spring架构中的重要区别

在使用aspectj进行定义pointcut时,经常碰到的问题就是该使用call还是execute。当然,在spring中,只支持execute,而不支持call,但使用aspectj如ltw时就可以使用,但两者究竟有什么区别,最大的区别在哪儿,适用点又在哪儿。这就要从定义出来,来了解相关信息了。

在文档《aspectj_in_action_second_editon.pdf》中,针对二者,主要如下面所述:

a call is on the caller side, whereas execution happens on the receiver side—they’re two completely different places. 

即call工作在调用端,而execute工作在被调用端。
如我们将在pointcut打印一句helloworld。那么针对helloAction调用helloService而言。针对call调用,这句打印将会在helloAction中调用,而execute调用,而是在helloService中调用。

以上只是表面上的区别,在具体使用时其实并不是太大的差别,但如果有以下一句话,那么区别就可能完全不一样了:

aspectj是通过修改字节码来完成相应的功能,通过在相应的pointcut定义指定的advice来完成功能。

具体点说,就是aspectj首先需要能够匹配到相应的pointcut,然后才能执行相应的advice方法,如果不能匹配到pointcut,那么就不能执行相应的方法。

继续阅读“aspectj中call和execute在spring架构中的重要区别”

Spring中Autowired注解,Resource注解和xml default-autowire工作方式异同

前面说到了关于在xml中有提供default-autowire的配置信息,从spring 2.5开始,spring又提供了一个Autowired以及javaEE中标准的Resource注释,都好像可以实现类似的自动注入。那么是不是每个都实现同样的方式呢,这里面的几个配置到底有哪些异同点。哪个更全,哪个更优先,这些都需要对spring的内部原理有详细的了解才可以进行了解。
在以下文章时,首先有几个概念需要列出:
字段名称:即fieldName,这个即propertyDescriper的getPropertyName返回信息。
setter名称:即方法setter除set之外的名称,如setAbc,则名称为abc,这里的abc不一定和fieldName相同。
参数名称:即在参数中所定义的参数的名称,如setAbc(Abc a123)。这里的参数名称就是a123。
本文所使用spring版本为spring3.0.2。

处理类和处理顺序异同

default-autowire是在xml中进行配置的,而这个配置从spring初始就提供了。而Autowired注解,则是从2.5自支持以java1.5之后才出现的,这就必然导致对相应的处理以及逻辑是不同的。那么每个方式的处理顺序是怎样的呢,从我写的文章:Spring中获取一个bean的流程-2.也可以由下面的代码得出:

		if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME ||
				mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
			MutablePropertyValues newPvs = new MutablePropertyValues(pvs);

			// Add property values based on autowire by name if applicable.
			if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) {
				autowireByName(beanName, mbd, bw, newPvs);
			}

			// Add property values based on autowire by type if applicable.
			if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
				autowireByType(beanName, mbd, bw, newPvs);
			}

			pvs = newPvs;
		}
......
			for (BeanPostProcessor bp : getBeanPostProcessors()) {
				if (bp instanceof InstantiationAwareBeanPostProcessor) {
					InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
					pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);

以上代码来源于类AbstractAutowireCapableBeanFactory的populateBean方法。从上可以看出,spring首先处理在bean定义上的autowire属性,然后再处理后面的InstantiationAwareBeanPostProcessor类。首先bean定义上的autowire属性,可以来自于<bean>定义时autowire属性,也可以来自于整个xml定义中<beans>节点中的default-autowire属性。

那么@Autowired注解和@Resource注解在哪儿处理呢,看上面的代码,有个InstantiationAwareBeanPostProcessor类,如果你仔细查看里面的实现,你可以发现里面即为处理相应注解类的实现。而这些注解类,只要在xml中启用了<context:annotation-config/>,即可以开启这些类了。而我们的Autowired注解,由AutowiredAnnotationBeanPostProcessor来进行处理,而Resource类,则由CommonAnnotationBeanPostProcessor进行处理。

继续阅读“Spring中Autowired注解,Resource注解和xml default-autowire工作方式异同”

在Mybatis-spring中由于默认Autowired导致不能配置多个数据源的问题分析及解决

在使用Mybatis中,通常使用接口来表示一个Sql Mapper的接口以及相对应的xml实现,而在spring的配置文件中,通常会使用MapperScannerConfigurer来达到批量扫描以及简化spring bean接口配置的目的,以直接让mybatis的各个接口直接成为spring的bean组件。那么,一个通常的spring配置文件如下所示:

	<bean id="datasource" class="org.springframework.jdbc.datasource.SimpleDriverDataSource"/>

	<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean" p:dataSource-ref="datasource"/>
	<bean id="sqlSessionTemplate" class="org.mybatis.spring.SqlSessionTemplate">
		<constructor-arg index="0" ref="sqlSessionFactory"/>
	</bean>
	<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
		  p:dataSource-ref="datasource"/>
	<bean  class="org.mybatis.spring.mapper.MapperScannerConfigurer"
		  p:basePackage="mapper"/>

上面的配置分别对应于一个基本的mybatis最需要的信息。值得需要注意的是,在配置MapperScannerConfigurer时,这里并没有指定sqlSessionFactoryName以及sqlTemplateName。在没有指定的情况下,spring就会指定默认的查找规则进行查询,如分别查找到默认的sqlSessionFactory实现和sqlSessionTemplate实现,并注入到MapperFactoryBean中。

这种配置方式,在一个数据源时,没有问题,但是在如果存在多个数据源时,上面的配置就存在问题了。在多个数据源时,如果配置不正确,或者配置的步骤不正确,将直接产生莫名奇妙的问题。而这个问题的产生,不在于开发人员,即不在于程序员本身,而在于spring,或来自于mybatis-spring,在其内部画蛇添足的注解,将导致整个多数据源配置完全不能工作。

继续阅读“在Mybatis-spring中由于默认Autowired导致不能配置多个数据源的问题分析及解决”

Spring中获取一个bean的流程-2

上篇,进入第4节,实质性地创建一个Bean信息。

4 doCreateBean

4.1 首先创建一个原始对象的包装对象,即BeanWrapper,这通过对bean进行包装而来,如下代码所示:

instanceWrapper = createBeanInstance(beanName, mbd, args);

在这个createBeanInstance方法中,首先会创建原始对象,这就有几个策略。如下所示:
如果存在工厂方法,即在xml中定义了factory-method,就会调用工厂方法进行创建,代码如下所示:

if (mbd.getFactoryMethodName() != null) {
			return instantiateUsingFactoryMethod(beanName, mbd, args);
		}

如果已经确认或者解析了候选构造方法,则调用此方法进行创建

if (resolved) {
			if (autowireNecessary) {
				return autowireConstructor(beanName, mbd, null, null);
			}
			else {
				return instantiateBean(beanName, mbd);
			}
		}

如果存在SmartInstantiationAwareBeanPostProcessor并且对象解析出指定的bean Class有候选的构造方法,如在构造方法上追加@Autowired的话,会优化使用这个构造方法。
最后,采用默认的构造策略进行对象创建,如调用Class.newInstance()方法创建。

继续阅读“Spring中获取一个bean的流程-2”

Spring中获取一个bean的流程-1

本文从ClasspathXmlApplication进行入手,未考虑针对于Annotation的处理,仅从xml方向对getBean进行代码追踪,以形成一个完整的链条。以下代码从取得一个singleton对象入手进行分析。

1 获取Bean信息

1.1 首先这里会调用AbstractApplicationContext.getBean(String name),这个方法直接会转向1.2
1.2 进入方法AbstractBeanFactory.getBean(String name),这个方法会直接进入1.3
1.3 进入方法AbstractBeanFactory.doGetBean(final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly)。这个方法是获取bean的主要入口。此方法的详细叙述在第2节

2 doGetBean信息

2.1 首先这里会将传入的beanName进行转化。代码如下所示:

		final String beanName = transformedBeanName(name);
protected String transformedBeanName(String name) {
		return canonicalName(BeanFactoryUtils.transformedBeanName(name));
	}

转化有两个步骤,首先处理beanName为&XXX的格式,这里表示要取指定name的factoryBean。在这里先把&符号取消,先获取bean再处理。然后,针对bean的alias机制,这里传入的参数可能是一个bean别名,那么我们先获取这个bean的主要id,只需要根据id值取bean就可以了。

继续阅读“Spring中获取一个bean的流程-1”