+++ 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[130.144.164.171:49173]) 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):
3.1

How reproducible:
Always

--- 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.