views:

693

answers:

1

I'm using/anticipating the following technology stack:

  • JSF
  • Seam
  • jBPM
  • Spring

Of course, I'd like Seam to access Spring beans directly and have got this much to work fine. I'd now like to move down into jBPM and develop a proof of concept process definition that accesses Spring beans to perform actions and make decisions.

To promote separation of concerns and ensure the processes can run without Seam in the class path I'd like a solution that DOES NOT permit access to all of the Seam managed components.

I know Seam uses a bespoke EL resolver but other than that, where do I start?

A: 

Its possible to subtype VariableResolver and specify your subtype in your jbpm.cfg.xml file. This can allow #{myBean} to resolve to your bean.

<jbpm-configuration>

    <bean name="jbpm.variable.resolver" class="com.your.jbpm.VariableResolver" singleton="true" >
     <field name="backingVariableResolver"><ref bean="jbpm.variable.backingResolver" /></field>
    </bean>
    <bean  name="jbpm.variable.backingResolver" class="org.jbpm.jpdl.el.impl.JbpmVariableResolver" singleton="true" />

</jbpm-configuration>

but for access from scripts and actions the way is to inject transient variables into the process instance, keeping in mind you may need to work around bug JBPM-304, by e.g. sub typing Script and adjusting the associated hibernate mapping files. This injection has to be repeated before each signal to each process instance.

These techniques can be used to ensure you have access to the beans you want access to, but don't really give you a custom EL. That would take some serious hacking of the JbpmExpressionEvaluator class.

Simon Gibbs