Bug 879062

+++ This bug was initially created as a clone of Bug #844434 +++

Description of problem:


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


How reproducible:
always

Steps to Reproduce:
1. Start eap in domain mode
2. Enter to "profle=full-ha, subsystem=modcluster, mod-cluster-config=configuration," 
3. unset proxy URL
4. Save configuration
  
Actual results:
ProxyURL gets changed by rhqadmin user, and then gets back to old value by "no-user"

Expected results:
Proxy URL should be set as "undefined"

Additional info:
No error in history,
Warn in agent log:

 2012-07-30 17:30:27,990 WARN  [ResourceContainer.invoker.daemon-47] (rhq.modules.plugins.jbossas7.ASConnection)- We got a 500 with the following response body back: {"outcome" : "failed", "failure-description" : "JBAS014792: Unknown attribute name", "rolled-back" : true

--- Additional comment from Armine on 2012-07-30 11:38:15 EDT ---

Additional information: Change of value from "smth" to "smth-else" works perfect, it reflects to only unsettling of the value.

--- Additional comment from Charles Crouch on 2012-07-30 11:48:50 EDT ---

Should be investigated as to whether this field should be required or if something else is going on here

--- Additional comment from Simeon Pinder on 2012-07-31 09:27:33 EDT ---

After some quick analysis this is a problem for other(non-modcluster) as7 resources as well. Unsetting of the ejb3 asynch service does not correctly clear the value.  Moving this to ON_DEV.

--- Additional comment from Simeon Pinder on 2012-08-02 10:29:30 EDT ---

So tracked down the problem and it's an issue executing an unset operation on any as7 resources based off of BaseComponent. That's almost all of them but is really only apparent on unset.  Set and udpate of resource configurations are unaffected.  This code was an optimization to not execute changes when 'null' values were passed in on a configuration update. 

The fix is to remove the optimization code, but this change also means that incorrect optional configuration attributes will now cause configuration update operations to fail with 'unknown attribute blah' on all updates.  An incorrect optional configuration attribute would be caused by an AS7 plugin definition that became stale after attribute name changes between as7 versions.  

Ex. modcluster attribute 'domain' -> 'load-balancing-group'. 

This meant that modcluster configuration update was broken but would never be detected.  Consequently there can be many other places in the AS7 tree where configuration update will be broken after this fix. 

I'm going to try to spend some time today trying to write some code to detect/verify our plugin definition against a given as7 instance if it's not too difficult.

--- Additional comment from Heiko W. Rupp on 2012-08-02 10:34:44 EDT ---

To add to the above analysis: RHQ plugins only get the new configuration, but no diff with respect to the previous configuration, which makes live hard.
With removal of the optimization, we now send dozens of :write-attribute(name,null) operations over the wire (inside a composite operation), just because we can not distinguish between "attribute was and is null" and "attribute became null".

--- Additional comment from John Sanda on 2012-08-02 14:52:02 EDT ---

JON 3.1.1 ER1 build is available. Moving to ON_QA.

https://brewweb.devel.redhat.com/buildinfo?buildID=226942

--- Additional comment from John Sanda on 2012-08-02 16:27:44 EDT ---

Moving back to ON_DEV. This should not have been moved to ON_QA as noted in comment 6.

--- Additional comment from Simeon Pinder on 2012-08-07 09:10:27 EDT ---

*** Bug 843514 has been marked as a duplicate of this bug. ***

--- Additional comment from Simeon Pinder on 2012-08-09 09:34:12 EDT ---

I think we should push this issue out of 3.1.1 as fixing it without addressing 847021 first could stop users from being able to update as7 configurations and execute operations where they would have been able to before the fix was applied for this issue.

In the even that we proceed with applying this issue anyway, and I am unavailable, Heiko should know the exact line number to change in the root BaseComponent as we discussed it.

--- Additional comment from Charles Crouch on 2012-08-14 14:04:45 EDT ---

As per triage mtg, moving this to jon312 to correspond to 847021.

--- Additional comment from mark yarborough on 2012-11-20 15:45:40 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).