Custom ELResolver

[tbe]

Hi!

For my current project it would be very helpfull to inject my own, custom ELResolver into the engine. My customer uses a very "flexible" bean structure with configurable classes and properties, there is no way to implement this with simple setter and getters. I would like to reflect this structure with my own resolver. Otherwise, writing scripts would be very very painfull…

Unfortunally, the EL resolvers inside activiti are only created in hardcoded methods and there is no point to inject my own ones. Is there any plan to change this or anything I didn't see?

Thanx + best regards,
Tom

[frederikherema1]

Tom,

Take a look in the ProcessEngineFactoryBean, this uses a custom SpringExpressionManagers, which adds an ELResolver to handle spring-beans. This way, you can use all your spring-beans. If using spring-beans doesn't cut it, you could write a similar mechanism as done there: creating your own expression-manager, which creates composite EL-resolver containing your custom EL-resolving logic.

Currently, there is no easier way of plugging in custom ELResolvers…

[tbe]

Frederik

thanks for your very fast help! I didn't use the spring configuration before, but now I inherited the spring ProcessEngineFactoryBean and was able to inject my own ELResolver. Inside expressions, I am now able to access spring resources and use own resolvers.

But I have a second question: Is it possible to reach spring beans from ScriptTasks (Groovy) and to use custom ELResolvers there, too?

Best regards,
Tom

[frederikherema1]

Hi,

Using beans in scripts will be available in activiti 5.3 (http://jira.codehaus.org/browse/ACT-97), which will be released beginning of march.

[tombaeyens]

Also the ProcessEngineConfigurationImpl has a configurable property expressionManager (class ExpressionManager);  If your configure a specialized version of it, you can overwrite the method createElResolver

[iravanchi]

I've extended the base ExpressionManager to allow me to add any number of ELResolvers using spring context. Here's the code:


public class ExtendedExpressionManager extends ExpressionManager
{
private List<ELResolver> extendedResolvers;

@Override
protected ELResolver createElResolver(VariableScope variableScope)
{
  ELResolver baseResolver = super.createElResolver(variableScope);

  CompositeELResolver result = new CompositeELResolver();

  for (ELResolver resolver : extendedResolvers)
   result.add(resolver);

  result.add(baseResolver);
  return result;
}

public void setExtendedResolvers(List<ELResolver> extendedResolvers)
{
  this.extendedResolvers = extendedResolvers;
}
}

If this code is added to the ExpressionManager itself by the developers, it allows easier addition of ELResolvers.

[ronald_van_kuij]

I don't think it should be added to the default expression manager since it would require everyone to use Spring. But making the expressionmanager itself configurable, would allow you to configure a custom expressionmanager and configure the additional resolvers.

But these are just my two cents

[iravanchi]

Hi,

This doesn't force everyone to use Spring at all. There's no dependency to Spring here.
You can set the property directly by calling the setter method and configure the ExpressionManager in pure Java.

-Hamed

[ronald_van_kuij]

Sorry, I see… (to quick to react originally to prevent getting a dependency on spring in our (my) project ;-))

The order of resolvers my be important though (performace wise i've noticed) , this is currently fixed in the code, but we could make that configurable to this way, and even disable resolvers right?