steps to reproduce: * inventory some jbas instance with a secured invoker * edit the plugin configuration of the corresponding discovered / import resource to match the invoker credentials * navigate to the resource browser and uninventory the resource * either wait (an amount of time equal to the runtime discovery period), or execute "discovery -f" on the corresponding agent * you'll notice that the jbas instance comes back into inventory, is green, has all of its children committed which are also green, BUT - and here's the odd part - the principal / credentials are UNset (the correct defaults)
See also JBNADM-3302
The behaviour of the AS instance is very inconsistent. Upon multiple repetitions of Inventoring / Uninventoring of a JBAS instance the instance comes in red after it was earlier in green without having the connection properties set. The tracing of the debugging indicates that the credentials / principal properties are being passed correctly on the agent side and on the JBoss AS side. Could the caching be taking place on the server side?
Upon editing the connection properties of a previously uninventoried resource, the principal and credentials are only validated when they're entered into the form. i.e. If those properties are set to be wrong then the system validates them, however if they're set to be null or not set to be updated (checkboxes are not set) then the connection is properly validated
* The discovery of JBoss AS instances is working fine, the connection properties are not cached on the discovery layer. * The agent is communicating the discovered resource to the server properly, the connection properties are not cached on that layer as well. * The import mechanism is working fine, there are no traces of the connection properties there. However upon import the resource is still marked as available. What I'm suspicious about is this: The JBossASComponent contains the following: (line 265-271) ConnectionProvider connectionProvider = connectionFactory.getConnectionProvider(connectionSettings); this.connection = connectionProvider.connect(); // TODO: Throw an InvalidPluginConfigurationException if we are able to connect but not authenticate. // Some changes to the EMS connect() method may be required to do this. (ips, 07/17/07) this.connection.loadSynchronous(false); As suggested by Ian I'll try to surround this with a try / catch block and null the connection if an exception is thrown. Otherwise the problem needs to be resolved on the EMS side.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-501 This bug is related to RHQ-945
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs. keyword: new = Tracking + FutureFeature + SubBug
making sure we're not missing any bugs in rhq_triage
sunil - please take a look at this. note the repro steps in the first comment.
Tested in RHQ build#438 Inventoried a eap5.1 jbas instance with a secured invoker (Uncommented admin=admin in "eap5.1/jboss-5.1.0.Branch/server/default/conf/props/jmx-console-users.properties" file) Navigated to 'Inventory->Connection Properties' tab of the resource. Entered and saved values 'admin' in 'Principal' and 'Credentials' text fields. Navigated to the resource browser and uninventoried the resource Executed "discovery -f" on the corresponding agent. Imported the jbas instance to inventory. Observed that the resource is green, has all of its children committed which are also green, However the the principal / credentials are unset. The fields did not show the values (admin/admin)