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的配置类型部分，详细讲解这个内容。