Description of problem:
A HibernateException with the following error message is getting thrown when updating a configuration,
collection with cascade="all-delete-orphan" was no longer referenced by the
owning entity instance: org.rhq.core.domain.configuration.PropertyMap.map
This issue was initially found in bug 586943 in which a group resource configuration update was failing. It was later encountered again in bug 600365 in which a group plugin configuration update was failing. For both of these bugs, we worked around the exception by creating a deep copy of the configuration object, stripping it of any hibernate proxies in the process. We have not yet been able to determine where/when a collection with cascade="all-delete-orphan" is getting dereferenced. It is quite possible that we will see this exception again somewhere else.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
I have done a good bit of investigation and although I have precisely pinpoint the problem, I have learned several things. First, the underlying causes of bug 586943 and bug 60035 is not related specifically to group config update operations. In the case of a group resource config update, it is a scheduled job that calls ConfigurationManagerBean.executeResourceConfigurationUpdate(int). That method in turn does a couple things. First it fetches the ResourceConfigurationUpdate object for the specified id. It then calls the agent remoting service.
I modified my local copy of ResourceConfigurationViewer to call ConfigurationManagerBean.executeResourceConfigurationUpdate() any time a configuration is loaded which happens any time you go to view a resource configuration. Sure enough this triggered the hibernate exception.
Commenting out the call to the agent service which is on/around 1102 in ConfigurationManagerBean and looks like,
causes the exception not to be thrown. I have not been able to reproduce the exception in an automated test. So at this point, we know that somehow, somewhere instances of PropertyList and PropertyMap are getting dereferenced from their parent Configuration objects, but we do not know we precisely why.
Since a considerable amount of time has already been spent investigating this and since we have a work around in creating a deep copy of the Configuration object, I am closing this out as WONTFIX.