Description of problem: When executing the login command, you get an error message saying "Failed to load manager ConfigurationManager due to missing class: java.lang.reflect.InvocationTargetException". Login succeeds but the ConfigurationManager object does not get initialized as a result of the error; consequently, the ConfigurationManager operations are not accessible. Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Start the cli (rhq-cli.sh) 2. Execute login command ($ login rhqadmin rhqadmin) 3. Actual results: RHQ - RHQ Enterprise Remote CLI 3.0.0.B03 Remote server version is: 3.0.0.B03(b2804ea) Failed to load manager ConfigurationManager due to missing class: java.lang.reflect.InvocationTargetException Login successful rhqadmin@localhost:7080$ Expected results: There should be no error initializing ConfigurationManager Additional info: The wrapped exception inside InvocationTargetException is a NoClassDefFoundError for PluginContainerException. In the 3.0.0 release, the API for ConfigurationManager (i.e., ConfigurationManagerRemote) has a dependency on PluginContainerException which is not a dependency of the CLI.
A temporary work around for this is to copy rhq-core-client-api-3.0.0-SNAPSHOT.jar into CLI_HOME/lib. That jar can be found in rhq.ear/lib. In the current implementation of ConfigurationManagerBean, it never throws PluginContainerException; so, simply removing PluginContainerException from ConfigurationManagerRemote resolves the issue. Depending on how ayoung implements validation for raw config, that exception may get propagated.
Debugging this was somewhat time consuming because the exception gets swallowed in RemoteClient.getManagers(). The exception is throw in that method, and it catches all exceptions and just prints a generic error message to std out. At a minimum, we should be logging the exception. And in the case of something like an InvocationTargetException where we know that actual exception is wrapped, we should at least attempt to log the underlying exception.
This issue was resolved during development some time ago.