From server log: 21:39:47,740 WARN [org.rhq.enterprise.server.util.CriteriaQueryGenerator] (http-/0.0.0.0:7080-87) Failed to add join fetch field on class [org.rhq.core.domain.configuration.ResourceConfigurationUpdate]: : java.lang.NoSuchFieldException: configuration ResourceConfigurationUpdate has a 'configuration' in its super-super-class More complete stacktrace: 21:39:42,900 WARN [org.rhq.enterprise.server.util.CriteriaQueryGenerator] (http-/0.0.0.0:7080-87) Failed to add join fetch field on class [org.rhq.core.domain.configuration.ResourceConfigurationUpdate]: : java.lang.NoSuchFieldException: configuration at java.lang.Class.getDeclaredField(Class.java:1901) [rt.jar:1.7.0_21] at org.rhq.enterprise.server.util.CriteriaQueryGenerator.addJoinFetch(CriteriaQueryGenerator.java:703) [rhq-enterprise-server-ejb3.jar:4.8.0-SNAPSHOT] at org.rhq.enterprise.server.util.CriteriaQueryGenerator.getQueryString(CriteriaQueryGenerator.java:357) [rhq-enterprise-server-ejb3.jar:4.8.0-SNAPSHOT] at org.rhq.enterprise.server.util.CriteriaQueryGenerator.getQuery(CriteriaQueryGenerator.java:767) [rhq-enterprise-server-ejb3.jar:4.8.0-SNAPSHOT] at org.rhq.enterprise.server.util.CriteriaQueryRunner.getCollection(CriteriaQueryRunner.java:99) [rhq-enterprise-server-ejb3.jar:4.8.0-SNAPSHOT] at org.rhq.enterprise.server.util.CriteriaQueryRunner.execute(CriteriaQueryRunner.java:70) [rhq-enterprise-server-ejb3.jar:4.8.0-SNAPSHOT] at org.rhq.enterprise.server.configuration.ConfigurationManagerBean.findResourceConfigurationUpdatesByCriteria(ConfigurationManagerBean.java:2384)
commit https://git.fedorahosted.org/cgit/rhq/rhq.git/commit/?id=078a2da4e488645284359940e3df7a61a0299109 Author: Lukas Krejci <lkrejci> Date: Fri May 24 16:43:50 2013 +0200 [BZ 965833 - Potential bug in join/fetch/avoidance code] It is now possible to lazily fetch fields defined in super classes. The avoidance of the join-fetch with limits exposed a missing feature that was present in the code from the day one. It would be failing if the criteria query was used to fetch a custom object (i.e. not the primary persistent class of the criteria object) using an "altered projection" and a fetch would be set on a field defined in a super class of the persistent class of the criteria object. Only by chance this has never happened before, because we don't use the altered projections on the criteria queries that often. Now that we lazily fetch fields much more often (to avoid join fetch with limits) this is a problem even in cases without an altered projection. The fix is fortunately very simple - we need to also search the superclasses of the criteria's persistent class when looking for a field to lazily fetch. The possibility of fields being present in super-classes was taken into account on other places in the CriteriaQueryGenerator class, too. Documentation on the getJoinFetchFields() and alterProjection() was enhanced to hopefully better explain the conditions underwhich you can combine fetching and altered projection together.