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.

Created attachment 606234 [details]
proposed patch

Attaching a proposed patch to apply to release/jon3.1.x branch.

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.

Hi,

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;
role.addPermission(Permission.VIEW_USERS);
var s = new Subject(userName, true, false);
s.setFirstName(firstName);
s.setLastName(lastName);
s.setEmailAddress(email);
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)".

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?

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))

The test got disabled in 8c899e866873bc253 in the release 311 branch.

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).

Lukas,
can you check the state of this one please?

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.

As per comment #12 this is in master and will be in ER1

verified


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

unconnected$ b = []
0 rows

unconnected$ 
unconnected$ assertEquals(a, b)

unconnected$