Bug 759167

Summary: Client side exception generated when viewing empty compatible group
Product: [Other] RHQ Project Reporter: John Sanda <jsanda>
Component: Core UIAssignee: Jay Shaughnessy <jshaughn>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.2CC: hrupp, jshaughn, skondkar
Target Milestone: ---   
Target Release: RHQ 4.3.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: 4.3 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-08-31 10:16:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 752488    
Attachments:
Description Flags
Possible patch none

Description John Sanda 2011-12-01 15:11:01 UTC 
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
--- STACK TRACE FOLLOWS ---
(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:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jay Shaughnessy 2011-12-01 16:03:39 UTC 
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 16:10:11 UTC 
Created attachment 539267 [details]
Possible patch
Comment 3 Jay Shaughnessy 2011-12-01 17:39:51 UTC 
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.
So:
- 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
issue.

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 12:09:32 UTC 
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 10:16:07 UTC 
Bulk close of old bugs in VERIFIED state.