"Two vararg methods with same score" for resteasy ClientWebTarget.request()

[Peter]

In OGNL 3.2.20 I'm experiencing the following log message. I think this error may be spurious here since there's a no-args method as well as 2 varargs methods.

Two vararg methods with same score(0): "public javax.ws.rs.client.Invocation$Builder org.jboss.resteasy.client.jaxrs.internal.ClientWebTarget.request(javax.ws.rs.core.MediaType[])" and "public javax.ws.rs.client.Invocation$Builder org.jboss.resteasy.client.jaxrs.internal.ClientWebTarget.request(java.lang.String[])" please report!

The OGNL statement being executed is:

someWebTarget.request().get()

Here's the method being called: https://github.com/resteasy/Resteasy/blob/main/resteasy-client/src/main/java/org/jboss/resteasy/client/jaxrs/internal/ClientWebTarget.java#L358

[Lukasz Lenart]

Are you sure you call request() with no params? OGNL has a test to confirm calling VarArgs method with null params, also I've added an additional test case and worked as expected.

[Peter]

I've just double-checked all other OGNL statements that are configured and all of them call request().

I built a unit test myself which appears to reproduce the issue against ognl:ognl:3.2.20 in central:

https://gist.github.com/petergeneric/d898dd50477d690cdedf9672ae945dc7

For me, the first assert passes (OGNL calls the right method), but the second assert that there's no stderr output fails

Hopefully it's not caused by me setting something up incorrectly - apologies in advance if that is the case!

[Lukasz Lenart]

Thanks a lot for your example, I was able reproduce this problem locally and what is more interesting it only happens in nested expressions like get().request()

[Lukasz Lenart]

I found the source of the problem, by introducing #69 something has been broken, using
-Dognl.security.manager=forceDisableOnInit solves the problem.

[Lukasz Lenart]

Which version of Java do you use? Upgrading Java to version 8 solves the problem, so maybe it's time to abound Java 1.7 in OGNL and start using Java 8 🤔

[Lukasz Lenart]

@harawata what do you think about this ^^?

[Peter]

I'm using a range of versions (it's an app suport framework), 1.8 LTS, 11 LTS and 16 (16 to be dropped whe 17 LTS comes out), this particular app was running on 16 (as was the unit test)

[Iwao AVE!]

Hi @lukaszlenart @petergeneric !

I just took a quick look and the error does not depend on Java version, but it is not 100% reproducible.
Basically, the test result depends on the order of the methods returned from Class#getDeclaredMethods() which varies on every run.

There are several logical issues.

1. The method OgnlRuntime#areArgsCompatible() currently returns the same score for the three request methods, but it should give the one with no arguments higher lower score when there is no arguments.
2. The condition of this line looks incorrect (mm.score > score should be mm.score < score).
3. To eliminate the order-dependency that I mentioned, reporting this particular error (i.e. "Two vararg methods with same score ...") may have to wait until all methods are evaluated.

[EDIT]
Sorry! Smaller score means better match. Edited 1 and deleted 2.

[Lukasz Lenart]

Thanks a lot @harawata for your insights! I will try to improve the code base on your ideas. Yet I would like to know if switching to Java 8 would be a problem for you?

[Iwao AVE!]

Hi @lukaszlenart ,
MyBatis 3.5.x requires Java 8, so there is no problem on our side.
Thank you for checking!

[Lukasz Lenart]

@petergeneric I have pushed OGNL 3.2.21-SNAPSHOT into https://s01.oss.sonatype.org/content/repositories/snapshots/ - could you test it?

[Peter]

@lukaszlenart looks good to me, thanks (Maven couldn't find 3.2.21-SNAPSHOT on s01.oss or oss., but I found and used 3.2.21-20210509.182701-1 on oss.sonatype which looks like the right artifact from the timestamp).

I ran the test several times against JDK10 and JDK11 and didn't get any errors.

[Lukasz Lenart]

@petergeneric great, thanks a lot for your help!