+++ This bug was initially created as a clone of Bug #845118 +++ Description of problem: Plugins like Infinispan plugin may fail with java.lang.Exception: Discovery component invocation failed. at org.rhq.core.pc.util.DiscoveryComponentProxyFactory$ComponentInvocationThread.call(DiscoveryComponentProxyFactory.java:297) [...] Caused by: java.lang.NoClassDefFoundError: org/rhq/plugins/jmx/ObjectNameQueryUtility at org.infinispan.rhq.CacheManagerDiscovery.createDiscoveredResource(CacheManagerDiscovery.java:76) at org.infinispan.rhq.CacheManagerDiscovery.discoverResources(CacheManagerDiscovery.java:62) Turns out we moved the ObjectNameQueryUtility to the util sub-package in commit d06bde3ab789c06f603836525d7281e7a96bad85 on 2012-01-20 --- Additional comment from hrupp on 2012-08-01 16:35:17 EDT --- master 4f60260d2afe0
We should rather make sure, that we don't make such incompatible changes. Those classes are "the public api" of the JMX plugin. Can we add a unit-test to hold this public API of the JMX plugin constant? Can we change the animal-sniffer to detect changes in the public API of the JMX plugin? I would truly like to prevent the introduction of further regressiosn of this type.
also ... can we do a code search to identify what other plugins may have regerssed because of this change?
task for the QE countermeasure. https://engineering.redhat.com/trac/jon/ticket/253 i would also like a dev countermeasure included here ...
release branch af6c7aa
Moving to ON_QA since JON 3.1.1 ER2 build is availble - https://brewweb.devel.redhat.com/buildinfo?buildID=228250
dev added an api diff checker to take care of this.