在工作中碰到了这种情形,苦逼了,特此记下来,以防下次出现。
有一个回调接口,做大文件解析用的,文件以xml方式存在某地,用SAX方式解析XML;
而在判断需要解析的文件是什么type类型时,原代码就根据type来用了一连串的if()else()来处理。所以看到这,就想改造它一下。
于是,用策略和简单工厂模式去处理了这些分支判断的问题,这样就满足于开-闭原则,降低了耦合,易于扩展。可是,代码的原功能不能正常运行了。
经过了多番调试,发现了这个隐藏的原因:
就是自动注入的服务的对象是new 来的,而不是通过Spring容器来管理。
所以报Spring @Autowired注入为null,空指针异常。
而这种处理方法就记录在下:
@Service("xxxService")
public class Xxxmpl implements Ixxx{
@Override
public void doSomething(){
//
}
}
public class BClazz{
@Autowired
private Ixxx xxxService;
public void doSomething(){
}
}
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
public class SpringContextUtil implements ApplicationContextAware{
// Spring应用上下文环境
private static ApplicationContext applicationContext;
/**
* 实现ApplicationContextAware接口的回调方法,设置上下文环境
*
* @param applicationContext
*/
public void setApplicationContext(ApplicationContext applicationContext) {
SpringContextUtil.applicationContext = applicationContext;
}
/**
* @return ApplicationContext
*/
public static ApplicationContext getApplicationContext() {
return applicationContext;
}
/**
* 获取对象
* 这里重写了bean方法,起主要作用
* @param name
* @return Object 一个以所给名字注册的bean的实例
* @throws BeansException
*/
public static Object getBean(String name) throws BeansException {
return applicationContext.getBean(name);
}
public static <T> T getBean(Class<T> requiredType) {
return applicationContext.getBean(requiredType);
}
}
后面还需要去配置文件里配置SpringContextUtil的配置信息。
最后,我还是没有用这个。个人觉得最后面都要改动到配置文件的信息,部署这个感觉改动有点大了,得不偿失。