osworkflow的工作流工厂
我们知道,osworkflow系统对osworkflow.xml中的<factory class="com.opensymphony.workflow.loader.XMLWorkflowFactory">
<property key="resource" value="workflows.xml" />
</factory>
以及对workflows.xml的
<workflows>
<workflow name="example" type="resource" location="/samples/comment-arg.xml"/>
</workflows>
解析,是放在workflowFactory中进行的;osworkflow的工作流工厂有几大类:
1)com.opensymphony.workflow.loader.XMLWorkflowFactory
2)com.opensymphony.workflow.loader.JDBCWorkflowFactory
3)com.opensymphony.workflow.loader.URLWorkflowFactory
他们都extends AbstractWorkflowFactory,并且他们的真正实现都是调用
WorkflowLoader.load(url)而实现的,所以他们的实现方法基本上是一样的,只不过他们的
cache实现方式不尽相同:
1)com.opensymphony.workflow.loader.XMLWorkflowFactory cache WorkflowConfig
2)com.opensymphony.workflow.loader.JDBCWorkflowFactory cache WfConfig
3)com.opensymphony.workflow.loader.URLWorkflowFactory cache WorkflowDescriptor
我们举例看看XMLWorkflowFactory的代码:
WorkflowConfig c = (WorkflowConfig) workflows.get(name);
if (c == null) {
throw new FactoryException("Unknown workflow name \"" + name + "\"");
}
if (c.descriptor != null) {
if (reload) {
File file = new File(c.url.getFile());
if (file.exists() && (file.lastModified() > c.lastModified)) {
c.lastModified = file.lastModified();
loadWorkflow(c);
}
}
}
else {
loadWorkflow(c);
}
return c.descriptor;
大家应该看到上面的代码就明白了,它用的是flyweight模式,只不过加了个中间层
WorkflowConfig而已;AgileFlow引擎对流程定义的解析使用的也是这个模式,它能够
实时判断用户对流程定义的修改并做出相应的反应.
页:
[1]