Bug 759167 - Client side exception generated when viewing empty compatible group
Client side exception generated when viewing empty compatible group
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
All All
medium Severity medium (vote)
: ---
: RHQ 4.3.0
Assigned To: Jay Shaughnessy
Mike Foley
Depends On:
Blocks: jon30-sprint9
  Show dependency treegraph
Reported: 2011-12-01 10:11 EST by John Sanda
Modified: 2013-08-31 06:16 EDT (History)
3 users (show)

See Also:
Fixed In Version: 4.3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-31 06:16:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
Possible patch (4.18 KB, application/octet-stream)
2011-12-01 11:10 EST, Heiko W. Rupp
no flags Details

  None (edit)
Description John Sanda 2011-12-01 10:11:01 EST
Description of problem:
I have a currently empty group of EAP 5 servers. The group is not recursive. When I go to the compatible groups page and click the name of my group, the following client exception is thrown:

com.google.gwt.core.client.JavaScriptException:(TypeError): Cannot read property 'org_rhq_core_domain_resource_Resource_resourceType' of undefined
(TypeError): Cannot read property 'org_rhq_core_domain_resource_Resource_resourceType' of undefined
   at Unknown.anonymous(Unknown source:0)
   at Unknown.at org_rhq_core_domain_resource_Resource_$getResourceType__Lorg_rhq_core_domain_resource_Resource_2Lorg_rhq_core_domain_resource_ResourceType_2(Unknown source:0)
   at Unknown.at org_rhq_enterprise_gui_coregui_client_inventory_groups_detail_summary_ActivityView$4_$onSuccess__Lorg_rhq_enterprise_gui_coregui_client_inventory_groups_detail_summary_ActivityView$4_2Lorg_rhq_core_domain_util_PageList_2V(Unknown source:0)
   at Unknown.at Object.org_rhq_enterprise_gui_coregui_client_inventory_groups_detail_summary_ActivityView$4_onSuccess__Ljava_lang_Object_2V [as onSuccess__Ljava_lang_Object_2V](Unknown source:0)
   at Unknown.at Object.com_google_gwt_user_client_rpc_impl_RequestCallbackAdapter_onResponseReceived__Lcom_google_gwt_http_client_Request_2Lcom_google_gwt_http_client_Response_2V [as onResponseReceived__Lcom_google_gwt_http_client_Request_2Lcom_google_gwt_http_client_Response_2V](Unknown source:0)
   at Unknown.at Object.org_rhq_enterprise_gui_coregui_client_util_rpc_TrackingRequestCallback_onResponseReceived__Lcom_google_gwt_http_client_Request_2Lcom_google_gwt_http_client_Response_2V [as onResponseReceived__Lcom_google_gwt_http_client_Request_2Lcom_google_gwt_http_client_Response_2V](Unknown source:0)
   at Unknown.at com_google_gwt_http_client_Request_$fireOnResponseReceived__Lcom_google_gwt_http_client_Request_2Lcom_google_gwt_http_client_RequestCallback_2V(Unknown source:0)
   at Unknown.at Object.com_google_gwt_http_client_RequestBuilder$1_onReadyStateChange__Lcom_google_gwt_xhr_client_XMLHttpRequest_2V [as onReadyStateChange__Lcom_google_gwt_xhr_client_XMLHttpRequest_2V](Unknown source:0)
   at Unknown.at XMLHttpRequest.<anonymous>(Unknown source:0)
   at Unknown.at com_google_gwt_core_client_impl_Impl_apply__Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2(Unknown source:0)
   at Unknown.at com_google_gwt_core_client_impl_Impl_entry0__Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2Ljava_lang_Object_2(Unknown source:0)

The group previously had members. It became empty as a result of my uninventorying the platform where all of the EAP servers were located.

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

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Jay Shaughnessy 2011-12-01 11:03:39 EST
I reproduced this pretty quickly.
1) Create new empty group
   - No problems, note that it is a mixed group
2) Add a member (I used an RHQAgent resource)
   - No problems, note that it is now compatible and has the type assigned
3) Uninventory the resource
4) Nav to All Groups
   - note that the type is still assigned and the group is still compat
5) Drill down and generate the exception

I'm not sure it's wrong to have an empty compatible group. In fact it
may be preferable, or even required, to resetting the group back to
mixed just because it is empty.  So that may be ok but possibly
we should be resetting it.

The problem actually seems to be generated by one of the resource
portlets, so it may not really be a problem with the group being
empty and compatible.  It may just be a false assumption in the portlet
code that a group isn't empty:

[INFO] (RPCTracker.java:82) 2011-12-01 10:58:26,155 [TRACE] RPCTracker queue depth is 6
[ERROR] (MessageCenter.java:92) 2011-12-01 10:58:26,251 [ERROR] At [Thu Dec 01 10:58:26 EST 2011] MessageCenter received: Globally uncaught exception
[INFO] (ErrorHandler.java:60) 2011-12-01 10:58:26,269 [WARN ] Globally uncaught exception
[INFO] java.lang.ArrayIndexOutOfBoundsException:
[INFO] 0
[INFO]     at org.rhq.enterprise.gui.coregui.client.inventory.groups.detail.summary.ActivityView$4.onSuccess(ActivityView.java:232)
[INFO]     at org.rhq.enterprise.gui.coregui.client.inventory.groups.detail.summary.ActivityView$4.onSuccess(ActivityView.java:1)

I'll look into it...
Comment 2 Heiko W. Rupp 2011-12-01 11:10:11 EST
Created attachment 539267 [details]
Possible patch
Comment 3 Jay Shaughnessy 2011-12-01 12:39:51 EST
master commit 81960e013533ee848aacc7716bf4bc254df93b2d

This turns out to be something of a happy accident.  The offending code
made an assumption that the group would not be empty. But looking more
closely it seems to me that the entire code block is unnecessary. Moreover,
it added a round trip to the DB when displaying the group level dashboard.
It was trying to determine whether to render the bundle deployment
portlet.  From what I can see, this can be determined already by looking
at the group's type's facets. And in fact the code was already in place.
- removing unnecessary db round-trip code (was even being done for
  mixed groups)
- keeping the existing facet-based code, which seems to do the right thing
- fixing a secondary problem that wrongly displayed the bundle deployment
  portlet for mixed groups.

So, Three fixes for the price of one!

Resource level code seems to work fine and does not have an analogous

Test Notes:
- use the repro steps to try this for the empty compat groups, for types
  both supporting and not supporting bundles.
- try populated compat groups, for types both supporting and not 
  supporting bundles.
  tip: you can use autogroups for this to save time.
- try mixed groups(should not have the bundle deployment portlet)
Comment 4 Sunil Kondkar 2011-12-09 07:09:32 EST
Verified in master build#825 (Version: 4.3.0-SNAPSHOT Build Number: e8db9a1)

Verified with repro steps for empty and populated compatible groups, for types   both supporting and not supporting bundles (EAP5 servers and RHQAgent for example)
Verified on mixed groups. No exception is observed.
Comment 5 Heiko W. Rupp 2013-08-31 06:16:07 EDT
Bulk close of old bugs in VERIFIED state.

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