spring prototype类型注入到 singleton作用域
在大部分情况下，容器中的bean都是singleton类型的。如果一个singleton bean要引用另外一个singleton
bean，或者一个非singleton bean要引用另外一个非singleton
bean时，通常情况下将一个bean定义为另一个bean的property值就可以了。不过对于具有不同生命周期的bean来说这样做就会有问题了，
比如在调用一个singleton类型bean A的某个方法时，需要引用另一个非singleton（prototype）类型的bean
B，对于bean A来说，容器只会创建一次，这样就没法在需要的时候每次让容器为bean A提供一个新的的bean B实例。
上述问题的一个解决办法就是放弃控制反转。通过实现BeanFactoryAware接口（见这里）让bean A能够感知bean 容器，并且在需要的时候通过使用getBean("B")方式（见这里）向容器请求一个新的bean B实例。看下下面这个例子，其中故意使用了这种方法：
// a class that uses a stateful Command-style class to perform some processing
package fiona.apple;
// lots of Spring-API imports
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
public class CommandManager implements BeanFactoryAware {
private BeanFactory beanFactory;
public Object process(Map commandState) {
// grab a new instance of the appropriate Command
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
// the Command returned here could be an implementation that executes asynchronously, or whatever
protected Command createCommand() {
return (Command) this.beanFactory.getBean("command"); // notice the Spring API dependency
}
public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
this.beanFactory = beanFactory;
}
}
上面的例子显然不是最好的，因为业务代码和Spring Framework产生了耦合。方法注入，作为Spring IoC容器的一种高级特性，可以以一种干净的方法来处理这种情况。
3.3.7.1. Lookup方法注入
这究竟是不是方法注入……
有点像Tapestry 4.0的页面，写上abstract属性，Tapestry会在运行时用具体实现将其覆盖。
在这篇Blog文章中你可以了解更过关于方法注入动机的内容。
Lookup方法注入利用了容器的覆盖受容器管理的bean方法的能力，从而返回指定名字的bean实例。在上述场景中，Lookup方法注入适 用于原型bean。Lookup方法注入的内部机制是Spring利用了CGLIB库在运行时生成二进制代码功能，通过动态创建Lookup方法bean 的子类而达到复写Lookup方法的目的。
如果你看下上个代码段中的代码(CommandManager类)，Spring容器动态覆盖了createCommand()方法的实现。你的CommandManager类不会有一点对Spring的依赖，在下面这个例子中也是一样的：
package fiona.apple;
// no more Spring imports!
public abstract class CommandManager {
public Object process(Object commandState) {
// grab a new instance of the appropriate Command interface
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
// okay... but where is the implementation of this method?
protected abstract Command createCommand();
}
在包含被注入方法的客户类中(此处是CommandManager)，此方法的定义必须按以下形式进行：
<public|protected> [abstract] <return-type> theMethodName(no-arguments);
如果方法是抽象的，动态生成的子类会实现该方法。否则，动态生成的子类会覆盖类里的具体方法。让我们来看个例子：
<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="command" class="fiona.apple.AsyncCommand" scope="prototype">
<!-- inject dependencies here as required -->
</bean>
<!-- commandProcessor uses statefulCommandHelper -->
<bean id="commandManager" class="fiona.apple.CommandManager">
<lookup-method name="createCommand" bean="command"/>
</bean>
在上面的例子中，标识为commandManager的bean在需要一个新的command bean实例时，会调用createCommand方法。重要的一点是，必须将command部署为prototype。当然也可以指定为 singleton，如果是这样的话，那么每次将返回相同的command bean实例！
请注意，为了让这个动态子类得以正常工作，需要把CGLIB的jar文件放在classpath里。另外，Spring容器要子类化的类不能是 final的，要覆盖的方法也不能是final的。同样的，要测试一个包含抽象方法的类也稍微有些不同，你需要自己编写它的子类提供该抽象方法的桩实现。 最后，作为方法注入目标的bean不能是序列化的(serialized)。
上述问题的一个解决办法就是放弃控制反转。通过实现BeanFactoryAware接口（见这里）让bean A能够感知bean 容器，并且在需要的时候通过使用getBean("B")方式（见这里）向容器请求一个新的bean B实例。看下下面这个例子，其中故意使用了这种方法：
// a class that uses a stateful Command-style class to perform some processing
package fiona.apple;
// lots of Spring-API imports
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.BeanFactoryAware;
public class CommandManager implements BeanFactoryAware {
private BeanFactory beanFactory;
public Object process(Map commandState) {
// grab a new instance of the appropriate Command
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
// the Command returned here could be an implementation that executes asynchronously, or whatever
protected Command createCommand() {
return (Command) this.beanFactory.getBean("command"); // notice the Spring API dependency
}
public void setBeanFactory(BeanFactory beanFactory) throws BeansException {
this.beanFactory = beanFactory;
}
}
上面的例子显然不是最好的，因为业务代码和Spring Framework产生了耦合。方法注入，作为Spring IoC容器的一种高级特性，可以以一种干净的方法来处理这种情况。
3.3.7.1. Lookup方法注入
这究竟是不是方法注入……
有点像Tapestry 4.0的页面，写上abstract属性，Tapestry会在运行时用具体实现将其覆盖。
在这篇Blog文章中你可以了解更过关于方法注入动机的内容。
Lookup方法注入利用了容器的覆盖受容器管理的bean方法的能力，从而返回指定名字的bean实例。在上述场景中，Lookup方法注入适 用于原型bean。Lookup方法注入的内部机制是Spring利用了CGLIB库在运行时生成二进制代码功能，通过动态创建Lookup方法bean 的子类而达到复写Lookup方法的目的。
如果你看下上个代码段中的代码(CommandManager类)，Spring容器动态覆盖了createCommand()方法的实现。你的CommandManager类不会有一点对Spring的依赖，在下面这个例子中也是一样的：
package fiona.apple;
// no more Spring imports!
public abstract class CommandManager {
public Object process(Object commandState) {
// grab a new instance of the appropriate Command interface
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
// okay... but where is the implementation of this method?
protected abstract Command createCommand();
}
在包含被注入方法的客户类中(此处是CommandManager)，此方法的定义必须按以下形式进行：
<public|protected> [abstract] <return-type> theMethodName(no-arguments);
如果方法是抽象的，动态生成的子类会实现该方法。否则，动态生成的子类会覆盖类里的具体方法。让我们来看个例子：
<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="command" class="fiona.apple.AsyncCommand" scope="prototype">
<!-- inject dependencies here as required -->
</bean>
<!-- commandProcessor uses statefulCommandHelper -->
<bean id="commandManager" class="fiona.apple.CommandManager">
<lookup-method name="createCommand" bean="command"/>
</bean>
在上面的例子中，标识为commandManager的bean在需要一个新的command bean实例时，会调用createCommand方法。重要的一点是，必须将command部署为prototype。当然也可以指定为 singleton，如果是这样的话，那么每次将返回相同的command bean实例！
请注意，为了让这个动态子类得以正常工作，需要把CGLIB的jar文件放在classpath里。另外，Spring容器要子类化的类不能是 final的，要覆盖的方法也不能是final的。同样的，要测试一个包含抽象方法的类也稍微有些不同，你需要自己编写它的子类提供该抽象方法的桩实现。 最后，作为方法注入目标的bean不能是序列化的(serialized)。
