This issue was reported in JBoss ON 3.2 update-01. We need to get this fix in 3.3 and verified.

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

From Heiko e-mail thread:

Hey,
I saw the below fly by in the server log :

12:04:44,258 WARN [org.rhq.enterprise.server.util.CriteriaQueryRunner]
(http-/0.0.0.0:7080-6) Could not initialize private
org.rhq.core.domain.alert.AlertDefinition
org.rhq.core.domain.alert.Alert.recoveryAlertDefinition

Attaching with a debugger shows that seems to come from the recently
fired alerts portlet and internally from
org.rhq.enterprise.server.util.CriteriaQueryRunner#initialize

--- Additional comment from Jay Shaughnessy on 2013-11-01 09:25:55 EDT ---

> OK, this is not directly related to recovery alert definitions. It's
> producible just using alerts that *don't* have a recovery alert def
> associated. Meaning, your everyday, typical alerts. When we perform the
> recent alerts query in the portlet (see
> AbstractRecentAlertsPortlet.AlertsPortletDataSource.getFetchCriteria()) we
> pull the optional data for the recovery alert definition
> (criteria.fetchRecoveryAlertDefinition(true)).

> As an aside, it's not immediately clear why we do this because on casual
> inspection it's not used.

> Anyhow, the issue is that this QueryCriteriaRunner code now tries to hydrate
> requested hibernate proxies into entities (Hibernate.initialize) but in this
> case the proxy is wrapping nothing. i.e., the recovery AlertDefinition id is
> 0 because there is no recovery alert def. The fact that this happens is very
> unusual. It's due to the fact (for reasons that I'm sure are obscure) that
> this field is not nullable. Meaning we set it to 0 as opposed to letting it
> be null in the DB. So the entity actually gets a proxy for nothing as
> opposed to the typical null value.

> The code doesn't die, it generates a WARN in QueryCriteriaRunner.initialize()
> because it does not expect to have a problem hydrating the proxy. But this
> will be very disconcerting in the logs, as the portlet will generate the
> warnings on every refresh when there are alerts.

> We have a few options:
> 1. guard against the 0 id case and don't try to hydrate (may be slightly
> tricky as we'd have to play with a proxy object)
> 2. catch and ignore (or log.debug) EntityNotFoundException on hydrate (and we
> should likely set the field null here as well, if possible)
> 3. change Alert.recoveryAlertDefinition to be optional (may be OK but an
> entity change seems risky of regression due to unknown deps)
> 4. look the other way and just change the portlet criteria to not ask for
> this optional data (would need to make sure we don't need it)
> 5. maybe others?

> Right now I'd recommend option (2). If for whatever reason we can't hydrate
> the entity field because it's not found, I think we should log as debug and
> continue. Any other exception we could catch and handle as a warn, like
> today.


... will implement option 2, although option 3 may be something we should look at in the future...

--- Additional comment from Jay Shaughnessy on 2013-11-01 13:52:19 EDT ---


master commit 29d66b177657a37fc126304408da49210c22a063
Author: Jay Shaughnessy <jshaughn>
Date:   Fri Nov 1 13:46:35 2013 -0400

    Handle the case where we have a required, lazy-loaded entity that may be set
    to 0.  We shouldn't do that, but we do.

--- Additional comment from Heiko W. Rupp on 2014-04-23 08:31:16 EDT ---

Bulk closing of 4.10 issues.

If an issue is not solved for you, please open a new BZ (or clone the existing one) with a version designator of 4.10.