Activiti Spring bean and overloaded method error.

[unsavory]

I have the following Spring bean methods:

/**
    * Whether or not to auto-reject this applicant based on the 
    * AutoRejectConfigItem rules configured in the system.
    * 
    * @param user - The user to check.
    * @return - Whether or not to auto-reject.
    */
   public boolean isUserAutoRejectCandidate(User user);
   
   /**
    * Whether or not to auto-reject this applicant based on the 
    * AutoRejectConfigItem rules configured in the system.
    * 
    * @param email - The email address of the {@link seah.model.User} to check.
    * @return - true/false
    * @throws AppException - If the user cannot be found.
    */
   public boolean isUserAutoRejectCandidate(String email) throws AppException;‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I'm calling one of them like this:

<conditionExpression xsi:type="tFormalExpression">${ userService.isUserAutoRejectCandidate(email) }</conditionExpression>‍

But I get the following exception:

Caused by: org.activiti.engine.impl.javax.el.ELException: Cannot coerce from class java.lang.String to class seah.model.profile.User
   at org.activiti.engine.impl.juel.TypeConverterImpl.coerceStringToType(TypeConverterImpl.java:287)
   at org.activiti.engine.impl.juel.TypeConverterImpl.coerceToType(TypeConverterImpl.java:348)
   at org.activiti.engine.impl.juel.TypeConverterImpl.convert(TypeConverterImpl.java:365)
   at org.activiti.engine.impl.juel.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:418)
   at org.activiti.engine.impl.javax.el.BeanELResolver.coerceValue(BeanELResolver.java:582)
   at org.activiti.engine.impl.javax.el.BeanELResolver.coerceParams(BeanELResolver.java:574)
   at org.activiti.engine.impl.javax.el.BeanELResolver.invoke(BeanELResolver.java:479)
   at org.activiti.engine.impl.javax.el.CompositeELResolver.invoke(CompositeELResolver.java:397)
   at org.activiti.engine.impl.juel.AstMethod.invoke(AstMethod.java:91)
   at org.activiti.engine.impl.juel.AstMethod.eval(AstMethod.java:75)
   at org.activiti.engine.impl.juel.AstEval.eval(AstEval.java:50)
   at org.activiti.engine.impl.juel.AstNode.getValue(AstNode.java:26)
   at org.activiti.engine.impl.juel.TreeValueExpression.getValue(TreeValueExpression.java:114)
   at org.activiti.engine.impl.el.JuelExpression.getValue(JuelExpression.java:46)
   … 166 more

This seems like an issue with the reflection implementation in Activiti.

[jbarrez]

What is the type of the email parameter? It seems to me it's a plain string, while your operation expects a User object.

[unsavory]

Yes, it is a String.  I also have a similar method in my service that takes a User object (same number of parameters).  But looking at the reflection piece in Activiti, it only matches on number of arguments in the method and assumes this is the correct method to call.  Which it is not.

[frederikherema1]

That's actually JUEL-implementation we ship in the activiti codebase, for doing the expression resolving. Have you checked the JUEL issues/forum for similar behaviour?

[frankee787]

@unsavory

Were you able to resolve this issue?

I too am facing the same issue. I have two methods as follows


public User getUser(String username)

public User getUser(Integer userId)

Although I am passing a String as the argument , it tries to coerce it to an Integer


${structService.getUser(registrar)},

The value of the variable registrar is a String, but somehow its being coerced to an Integer.

Any idea why ?

Regards,
Franklin

[unsavory]

I never figured out what the issue was because I didn't have time to investigate the JUEL library like frederikheremans mentioned above.  The workaround for me was somewhat of a hack, but it works.  I just created a new method with a different name.  In your case you could have 2 methods: getUserByUsername and getUserById and it will work fine.

[frankee787]

Same over here. Never was able to figure it out. In the end I also created a new service with a different name. Was a hack but I too was short on time to figure it out.

Thanks anyways. Might be handy for someone else.

Regards,
Franklin

[smurfs]

Hi
can anyone please let me know, is  this still an issue. Because i am facing the same issue with 5.15.

[vasile_dirla]

Hi,
I think is related to this one:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56147

According to the EL specs method overloading is not supported (probably there are EL implementations which supports it but don't know to tell you which one.)

As I know EL get the methods via reflection calling this method:
<java>
public Method[] getMethods() throws SecurityException;
<java>

but in the documentation is written:
"The elements in the array returned are not sorted and are not in any particular order."
Which could lead to inconsistent behaviour for multiple EL calls.
the first call could succeed but the second one could fail (as you already noticed)
So the best solution is to create different methods having different names just to remove the confusion.

Have a look also here:
https://github.com/beckchr/juel/issues/72
JUEL documentation says: "If the given paramTypes is not null, select the method with the given name and parameter types. Else select the method with the given name that has the same number of parameters. If there are more than one such method, the method selection process is undefined. Else select the method with the given name that takes a variable number of arguments."

[vasile_dirla]

Hi,
I think is related to this one:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56147

According to the EL specs method overloading is not supported (probably there are EL implementations which supports it but don't know to tell you which one.)

As I know EL get the methods via reflection calling this method:
public Method[] getMethods() throws SecurityException;


but in the documentation is written:
"The elements in the array returned are not sorted and are not in any particular order."
Which could lead to inconsistent behaviour for multiple EL calls.
the first call could succeed but the second one could fail (as you already noticed)
So the best solution is to create different methods having different names just to remove the confusion.

Have a look also here:
https://github.com/beckchr/juel/issues/72
JUEL documentation says: "If the given paramTypes is not null, select the method with the given name and parameter types. Else select the method with the given name that has the same number of parameters. If there are more than one such method, the method selection process is undefined. Else select the method with the given name that takes a variable number of arguments."