Bug 880136

Summary: New DataSource trait "Connection Available?" causing errors in EAP Server.log
Product: [Other] RHQ Project Reporter: Heiko W. Rupp <hrupp>
Component: PluginsAssignee: Heiko W. Rupp <hrupp>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.5CC: dsteigne, hrupp, loleary, myarboro
Target Milestone: ---   
Target Release: RHQ 4.6   
Hardware: All   
OS: All   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 859417 Environment:
Last Closed: 2013-09-03 10:45:44 EDT Type: Enhancement
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 859417    

Description Heiko W. Rupp 2012-11-26 05:45:56 EST
+++ This bug was initially created as a clone of Bug #859417 +++

Description of problem:
The Datasource Trait "Connection Available?" represents the result of executing the `testConnection` method on the `jboss.jca:name=<data-source-name>,service=ManagedConnectionPool` MBean, which causes an error in the EAP server.log[1] because of [2].  Suggest that we set this trait to Disabled by default and make a note in the documentation about the effects of enabling it.

[1]  ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] (WorkerThread#1[]) Failed to load users/passwords/role files
java.io.IOException: No properties file: users.properties or defaults: defaultUsers.properties found
        at org.jboss.security.auth.spi.Util.loadProperties(Util.java:201)
        at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186)
        at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200)
        at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127)

[2] The JBossManagedConnectionPool.testConnection method first tries to create a security Subject that it can use as the security context to test the DB connection. If the datasource does not have a security domain, then the "other" security domain (defined in server/${PROFILE}/conf/login-config.xml) will be used to verify the security context. By default, the UsersRolesLoginModule is used for the "other" security domain and it is configured without a user or roles properties file. Not having a user or role properties file defined causes the security context validation checks to fail which causes the UsersRolesLoginModule.initialize method to log the error

Version-Release number of selected component (if applicable):

How reproducible:

--- Additional comment from Larry O'Leary on 2012-09-21 10:05:56 EDT ---

This issue is due to how EAP security is configured along with the datasource configuration and is detailed in from the EAP perspective in https://access.redhat.com/knowledge/solutions/54980.

If possible, we should look into what needs to happen to prevent the error or perhaps disable the trait by default?

--- Additional comment from Heiko W. Rupp on 2012-11-20 09:24:32 EST ---

That trait is marked as "summary", which means that it is shown in the header section (above the tabs) of the resource. Unmarking it as summary will disable its collection by default, but also remove it from the header section.
Having a displayType of summary also overrides a defaultOn setting, so just setting the later to 'false' is not enough.

If we follow that route, we need to document it in the release notes and also mention the security setting needed in the plugin descriptor description.

Another option could be to somehow check if security is configured correctly and if not disable the collection, but I think this bears more risk than it helps.

--- Additional comment from Larry O'Leary on 2012-11-20 09:48:09 EST ---

I would think that removing it from the summary section and setting it to disabled by default is ideal. Also, mentioning it in the release notes is probably a good idea seeing that users might already be relying on it for alert definitions in existing installations. 

If we did the latter, the only way I could see it being useful or of benefit is if we introduce different return types for the method--true, false, and unknown. Unknown could be treated as false but provide a visual difference from the users perspective with a definition meaning that we could not collect the trait due to configuration of the resource.
Comment 1 Heiko W. Rupp 2012-11-26 05:48:03 EST
master e6be4a4
Comment 2 Heiko W. Rupp 2013-09-03 10:45:44 EDT
Bulk closing of issues in old RHQ releases that are in production for a while now.

Please open a new issue when running into an issue.