Bug 850744 - assertEquals() fails in the CLI on native javascript arrays in JDK7
assertEquals() fails in the CLI on native javascript arrays in JDK7
Product: JBoss Operations Network
Classification: JBoss
Component: CLI (Show other bugs)
JON 3.1.0
Unspecified Unspecified
unspecified Severity low
: ER01
: JON 3.2.0
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On:
Blocks: 682878 848399 852094 852815
  Show dependency treegraph
Reported: 2012-08-22 06:05 EDT by Lukas Krejci
Modified: 2014-01-02 15:39 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 852094 (view as bug list)
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
proposed patch (5.11 KB, patch)
2012-08-22 08:18 EDT, Lukas Krejci
no flags Details | Diff

  None (edit)
Description Lukas Krejci 2012-08-22 06:05:01 EDT
Description of problem:
a = []
b = []

assertEquals(a, b)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run the above script in the CLI
Actual results:
javax.script.ScriptException: sun.org.mozilla.javascript.internal.EvaluatorException: The choice of Java constructor assertEquals matching JavaScript argument types (object,object) is ambiguous; candidate constructors are: 
    void assertEquals(java.util.Collection,java.util.Collection)
    void assertEquals(java.lang.Object[],java.lang.Object[]) (<Unknown source>#1) in <Unknown source> at line number 1
	at com.sun.script.javascript.RhinoScriptEngine.eval(RhinoScriptEngine.java:220)
	at com.sun.script.javascript.RhinoScriptEngine.eval(RhinoScriptEngine.java:236)
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
	at org.rhq.bindings.util.ScriptAssertTest.testWorks(ScriptAssertTest.java:143)
	... 35 more

Expected results:
the assertEquals() function should work

Additional info:
Comment 1 Lukas Krejci 2012-08-22 06:05:45 EDT
JDK7 bundles with a version of Rhino where the native arrays implement the Collection interfaces, which is not the case with Rhino bundled with JDK6.
Comment 2 Lukas Krejci 2012-08-22 08:18:36 EDT
Created attachment 606234 [details]
proposed patch

Attaching a proposed patch to apply to release/jon3.1.x branch.
Comment 3 Lukas Krejci 2012-08-22 08:21:15 EDT
Note that master/RHQ4.5.0 is not affected by this bug. It is specific to code based on RHQ 4.4.0 and earlier.
Comment 4 Armine Hovsepyan 2012-08-22 10:44:59 EDT

just did some sanity check with JON 3.1.1 ER3 CLI. 

The steps are:

var role = new Role();
role.name = roleName;
role.description = roleDescription;
var s = new Subject(userName, true, false);
var newUser = SubjectManager.createSubject(s);
SubjectManager.createPrincipal(newUser.getName(), password);
var sc = new SubjectCriteria();
var userCount = SubjectManager.findSubjectsByCriteria(sc);
assertTrue(userCount.size() > 1, "View Users permission doesnt work correctly!!");

var cnt = userCount.size(); 
assertEquals(cnt, 3); 

Everything works just perfect, without any exceptions, problems.

The step described by Lukas doesn't work - getting smth like "The choice of Java constructor assertEquals matching JavaScript argument types (object,object) is ambiguous; candidate constructors are: 
    void assertEquals(java.lang.Object[],java.lang.Object[])
    void assertEquals(java.util.Collection,java.util.Collection) (<Unknown source>#1)".
Comment 5 Mike Foley 2012-08-22 11:00:35 EDT

so Armine's testing provides the following information:

1) confirms the original issue
2) clarifies the scope.  so the issue is not widespread.... and the CLI is not entirely broken.

lukas has provided the proposed fix.  (thank you!)

so now i think the issue is perfectly ready for triage.  

the questions, i believe, are:  
how common a use-case for customers to encounter this issue?
which is riskier ... the issue?  or the fix?
Comment 6 Lukas Krejci 2012-08-22 12:34:43 EDT
So to clarify the scope, this bug only appears if the assertEquals() method is called with at least one parameter being a "native" javascript array (i.e. an array created through the script, not obtained from RHQ). Also, there might be some combinations of types of arguments which work even if one of them is a native array.

Alternatively to applying the patch, we can document this as a known issue on JDK7 and suggest a workaround:

a = []
b = []

assertEquals(new java.util.ArrayList(a), new java.util.ArrayList(b))
Comment 7 Heiko W. Rupp 2012-08-27 11:08:27 EDT
The test got disabled in 8c899e866873bc253 in the release 311 branch.
Comment 10 mark yarborough 2012-11-20 15:45:56 EST
Per triage with loleary, crouch, mfoley: Move to JBoss ON product, set target release JON 3.2, clear priority (will be subject to further triage in JON 3.2 timeframe).
Comment 11 Heiko W. Rupp 2013-08-12 07:38:44 EDT
can you check the state of this one please?
Comment 12 Lukas Krejci 2013-08-12 09:35:49 EDT
as per comment #3, this should be fixed in JON3.2.x codebase, because it is going to based on RHQ codebase no longer affected by this bug.
Comment 13 Heiko W. Rupp 2013-08-12 10:03:22 EDT
As per comment #12 this is in master and will be in ER1
Comment 14 Mike Foley 2013-09-13 15:40:53 EDT

unconnected$ [mfoley@foleymonsterbox1 bin]$ 
[mfoley@foleymonsterbox1 bin]$ 
[mfoley@foleymonsterbox1 bin]$ ./rhq-cli.sh
RHQ Enterprise Remote CLI 4.7.0.JON
unconnected$ a = []
0 rows

unconnected$ b = []
0 rows

unconnected$ assertEquals(a, b)


Note You need to log in before you can comment on or make changes to this bug.