Bug 785968 - cannot edit a template with more than 1 definition attached
cannot edit a template with more than 1 definition attached
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: drift (Show other bugs)
4.2
Unspecified Unspecified
high Severity high (vote)
: ---
: JON 3.0.1
Assigned To: John Sanda
Mike Foley
:
Depends On: 767328
Blocks: jon30-sprint10/rhq43-sprint10 jon310-sprint11/rhq44-sprint11
  Show dependency treegraph
 
Reported: 2012-01-30 22:14 EST by Charles Crouch
Modified: 2015-02-01 18:27 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 767328
Environment:
Last Closed: 2013-09-03 11:04:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2012-01-30 22:14:12 EST
+++ This bug was initially created as a clone of Bug #767328 +++

1) Create a drift template.
2) Go to resource #1 and create a drift definition from that template
3) Go to resource #2 and create a drift definition from that template
   (I'm not sure, but I think if you just create two definitions from the same template, even on the same resource, the same bug shows up, but I used two resources)
4) Edit the drift template (change the enabled flag, or the interval) and save

boom.

--- Additional comment from mazz@redhat.com on 2011-12-13 14:54:35 EST ---

git commit 9b42a3a83b51bdce587b6841774e373b25343e5a doesn't fix this bug, but it fixes another bug that shows up when basedir is null (which is the real problem - basedir should not be null). See the diff of that commit for details.

--- Additional comment from jsanda@redhat.com on 2011-12-13 17:27:21 EST ---

Template updates are propagated to attached definitions. This means that DriftManagerBean.updateDriftDefinition is invoked for each attached definition. Note that this all occurs within the same transaction. updateDriftDefinition sends a request to the agent to add/update the definition. To avoid hibernate proxy issues on the agent, we flush and clear the persistence context before calling the agent. When updateDriftDefinition is called for the second definition, the proxy for DriftDefinition.configuration has been cleared and we wind up with the following exception,

Caused by: java.lang.NullPointerException
        at org.rhq.enterprise.server.drift.DriftManagerBean.validateDriftDefinition(DriftManagerBean.java:804)
        at org.rhq.enterprise.server.drift.DriftManagerBean.updateDriftDefinition(DriftManagerBean.java:720)

The short term, temporary solution is to reload each definition before we call updateDriftDefinition.

master commit hash: ee66d10c7c3dee5a9c9bd102d9ea2db347e0e769

I was talking with mazz and jshaughn about a longer term solution that involves sending requests to agents out of band using quartz. The solution ought to be generic as it would have applicability in other places outside of drift code.

--- Additional comment from skondkar@redhat.com on 2011-12-14 06:58:45 EST ---

Verified on master build#833 (Version: 4.3.0-SNAPSHOT Build Number: ee66d10)

Imported two EAP5.x servers and created a drift template on JBossAS5 server. Created drift definitions from that template on both the EAP servers.
   
Verified that editing and saving the drift template does not throw any exception and the attached drift definitions are updated successfully.

Also verified by creating two definitions from the same template on the same resource and updating the template.

--- Additional comment from ccrouch@redhat.com on 2012-01-30 22:13:37 EST ---

Setting the Target Release version correctly to match where the issue was tested.
Comment 1 Charles Crouch 2012-01-30 22:15:34 EST
Fix needs to brought back from master and committed to the JON 3.0.1 branch (release/jon3.0.x), checked by engineering and then pushed to ON_QA when its available in a build for QE
Comment 2 John Sanda 2012-02-06 09:37:47 EST
The fix has been pushed to the release/jon3.0.x branch.

commit hash: d3ec74ff1488065b54e3b0b81eca0ba59ccfb2fd
Comment 3 Charles Crouch 2012-02-06 18:43:07 EST
Setting to MODIFIED while waiting for this to appear in a build
Comment 4 Simeon Pinder 2012-02-09 14:52:02 EST
Moving this to ON_QA as new RC3 binary available here:
https://brewweb.devel.redhat.com//buildinfo?buildID=198086
Comment 5 Mike Foley 2012-02-09 15:54:56 EST
verified JON 3.01 RC3
Comment 6 Heiko W. Rupp 2013-09-03 11:04:56 EDT
Bulk closing of old issues in VERIFIED state.

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