Red Hat Bugzilla – Bug 759167
Client side exception generated when viewing empty compatible group
Last modified: 2013-08-31 06:16:07 EDT
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:
--- 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):
Steps to Reproduce:
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] 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...
Created attachment 539267 [details]
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
- 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
- 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
tip: you can use autogroups for this to save time.
- try mixed groups(should not have the bundle deployment portlet)
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.
Bulk close of old bugs in VERIFIED state.