Delegation的配置类型
在Jbpm的userguide的第16.2.3节中，讲述了Delegation的四种配置机制。相对应的也就是config-type属性的四种可能的值。分别是“field，bean，constructor，configuration-property”。我建议读者先读一下userguide的第16.2.3节。
回忆一下，Delegation类有一个map成员instantiatorCache。它五个元素的key，除了null，其余四个正是我们上面列出的四个值。也就是说，在建模的时候，对于<action class=”dust.action.Action1Handler” config-type=”field”>元素， Action类的actionDelegation成员的instantiate()方法就会选择instantiatorCache中的FieldInstantiator对象来实例化dust.action.Action1Handler类。如果config-type=”bean”，那么就会选择BeanInstantiator。依次类推。
如果你不写config-type那么这个时候instantiatorCache的null就起作用了，所以默认还是FieldInstantiator。
那么FieldInstantiator，BeanInstantiator，ConfigurationPropertyInstantiator ，ConstructorInstantiator，四个类创建客户化对象有什么不同呢？
我们先写个类dust.action.Action1Handler，来看看。
public Action1Handler implements ActionHandler{
String name;
int count;
public Action1Handler(){}
public Action1Handler(String configuration){
System.out.println("==Action1Handler contstructor==");
System.out.println("==configuration is:"+configuration+"==");
}
public void setConfiguration(String configuration){
System.out.println("==Action1Handler setConfiguration==");
System.out.println("==configuration is:"+configuration+"==");
}
// getters and setters //////////////////////////////////////////////////////
public void setName(String name){
this.name = name;
}
public String getName(){
return this.name ;
}
public void setCount(int count){
this.count = count;
}
public int getCount(){
return count;
}
public void execute(ExecutionContext executionContext) throws Exception {
// TODO Auto-generated method stub
}
}
下面我们假设流程定义为中有
<action class=”dust.action.Action1Handler” config-type=”field”>
<name>dust</name>
<count>5</count>
</action>
5.1. FieldInstantiator类
当config-type为field时，或者没有config-type属性，会使用FieldInstantiator类。
FieldInstantiator类使用反射机制直接对类的成员进行赋值。
也就是说FieldInstantiator会直接将dust付给name，5付给count。
5.2. BeanInstantiator类
当config-type为bean时，会使用BeanInstantiator类。
BeanInstantiator类必须使用setter属性，来对成员赋值。
即，BeanInstantiator使用setName()和setCount()。如果没有这两个方法，那么就会在日志中报错。
5.3. ConstructorInstantiator类
当config-type为constructor时，会使用ConstructorInstantiator类。
ConstructorInstantiator类会调用客户类的具有一个String类型参数的构造函数。并且将<action>元素的所有内容作为字符串类型的参数，传给构造函数。客户可以在这个构造函数中自己处理这段xml文档。
也就是说Jbpm会调用 public Action1Handler(String configuration){}。
5.4. ConfigurationPropertyInstantiator类
当config-type为configuration-property时，会使用ConfigurationPropertyInstantiator类。
ConfigurationPropertyInstantiator类会调用客户类的具有一个String类型参数的一个名叫setConfiguration()方法。并且将<action>元素的所有内容作为字符串类型的参数，传给setConfiguration方法。客户可以在这个方法中自己处理这段xml文档。
也就是说Jbpm会调用 public void setConfiguration(String configuration){}方法。
在Jbpm执行一个流程实例过程中，当遇到一个Action时，会首先实例化流程定义中的Action元素指定的客户化类。如果没有指定config-type的话，那么会调用客户化类的默认构造函数。然后调用execute()方法。
如果config-type为field或bean的话，那么就会在调用execute()前进行属性赋值；如果config-type为constructor，那么就会调用有参数的构造函数；如果config-type为configuration-property是，会先调用默认构造函数，然后调用setConfiguration()方法。
就像Jbpm的文档中自己写的那样，Jbpm使用Delegation机制是为了在流程执行中能够使用用户自己定制的代码（user’s custom code）。
在jPDL的schema定义中，有四个元素是可以添加用户自己定制的类。那就是action，assignment，controller和handler。这四个元素都有两个共同的属性，class和config-type。其中，action元素中class所指定的类必须实现org.jbpm.graph.def.ActionHandler接口。Assignment元素的class所指定的类必须实现org.jbpm.taskmgmt.def.AssignmentHandler接口。controller元素的class所指定的类必须实现org.jbpm.taskmgmt.def.TaskControllerHandler接口。handler元素的class所指定的类必须实现org.jbpm.graph.node.DecisionHandler接口。
在这四个元素的schema定义中还都有一个没有Name属性的成员“{content}”。Jbpm对它的解释是“the content of the handler can be used as configuration information for your custom handler implementations. This allows the creation of reusable delegation classes.”我会在Delegation的配置类型部分，详细讲解这个内容。