EL: Invoking methods using parameters and el version clashes

[frederikherema1]

A very powerful feature of the EL 2.1.2 spec (part of Java EE6) is the possibility of invoking method calls with parameters. No doubt, this would be a great feature to have for developers to use in their process definitions.

For example, take assignment listeners (soon to be implemented by Joram). It would allow developers to use a method as assignment Listener. This way, he/she can pass execution variables into methods on existing (spring)beans, instead of forcing the developer to implement a one-liner Listener class that does the except same thing. This way, no hard link is explicitly needed to activity from the existing spring-beans, since we can just pass simple native java types (more loosely coupled).

JUEL 2.2.1 provides an implementation for the 2.1.2 spec. Unfortunately, we can't just use JUEL since the EL-version clashes with older 1.0. Therefore I suggest the following solution:

* Since JUEL is apache-licensed, we can modify and extend the source-code, of course complying to the http://www.apache.org/licenses/LICENSE-2.0.

* Refactoring the juel-api classes and rename all javax.el to another package-name so it doesn't collide with the javax.el. The juel-impl classes will now be detached from javax.el and would work in any environment.

* Since we use ActivitiExpression in activiti, a layer between the engine and the expression implementation, the switch from javax.el.ValueExpressions to our own will be transparent.

* We can add a mechanism that can, when running in EL 2.1.2 environment, eg. Tomcat 7 or glassfish EE6, switch to the default EL-strategy (using javax.el.ExpressionManagerFactory)  and use the environement/container provided 2.1.2 EL-implementation.

* We will build the modified JUEL as separate project (eg. activiti-juel or activiti-el) and add this as a dependency to activiti-engine, replacing JUEL-impl  dependency.

Any thoughts, remarks or suggestions are welcome!

[iravanchi]

The way you mentioned seems easy to do, and it also solves one of my issues too - the JAR issue in Tomcat 6. (EL jar file needs to be replaced in Tomcat's lib in order for Activiti to work)

But how are you going to keep-up with the updates on JUEL? This way, you need to re-do the above importing-renaming thing every time a new JUEL comes out, or forget about the updates / bugfixes.

[frederikherema1]

Now we are using the source-code in JUEL 2.2.1 tag, which is exactly the same codebase as found in the official release of JUEL 2.2.1 found in maven. In case there is a new version of JUEL and we absolutely need it, the importing and refactoring should be performed again. This is indeed a bit more hassle than just updating the version in the pom, but it's a choice we are willing to take in order to get the parameterised method-expressions in.

Also, JUEL's codebase is very stable and is build upon EL-spec that won't likely change again in the next couple of years.

[iravanchi]

It's totally convincing for me, specially the "JUEL being stable" point. Thanks for the reply.