Exception when testing Oracle datasource connections

[fibber]

For JBoss AS 6.0.0 M4, using Java 1.6.0_21 running on Solaris 10:

When I create a new Oracle datasource, the first thing I do is the "Test Connection" function (from Datasources -> datasource_name -> Control tab).  For some reason, I'm getting a stack trace with a security exception in the server log, even though the admin console is telling me that the connection test was successful.  This exception occurs no matter how simple or complicated my datasource connection is.  For example:

oracle-basic-ds.xml

<?xml version="1.0" encoding="UTF-8"?>

<datasources>

  <local-tx-datasource>

    <jndi-name>OracleDS</jndi-name>

    <driver-class>oracle.jdbc.OracleDriver</driver-class>
    <connection-url>jdbc:oracle:thin:@10.0.0.0:1521:MYSID</connection-url>
    <user-name>the_user</user-name>
    <password>the_password</password>

  </local-tx-datasource>
</datasources>

The admin console results show that the "Yes" radio button is selected in the Test Results section (for the item that says "Was a connection obtained").  I know the connection is working correctly because if I change the password in the *-ds.xml file, the "No" radio button is selected, along with an error being printed in the server log.

After the successful test, I see this large stack trace in the server log, telling me the users.properties and defaultUsers.properties files cannot be found:

0:38:45,020 ERROR [org.jboss.security.auth.spi.UsersRolesLoginModule] 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) [:3.0.0.Beta4]
        at org.jboss.security.auth.spi.UsersRolesLoginModule.loadUsers(UsersRolesLoginModule.java:186) [:3.0.0.Beta4]
        at org.jboss.security.auth.spi.UsersRolesLoginModule.createUsers(UsersRolesLoginModule.java:200) [:3.0.0.Beta4]
        at org.jboss.security.auth.spi.UsersRolesLoginModule.initialize(UsersRolesLoginModule.java:127) [:3.0.0.Beta4]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_21]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_21]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_21]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21]
        at javax.security.auth.login.LoginContext.invoke(LoginContext.java:756) [:1.6.0_21]
        at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [:1.6.0_21]
        at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [:1.6.0_21]
        at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_21]
        at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [:1.6.0_21]
        at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [:1.6.0_21]
        at org.jboss.security.plugins.auth.JaasSecurityManagerBase.defaultLogin(JaasSecurityManagerBase.java:553) [:3.0.0.Beta4]
        at org.jboss.security.plugins.auth.JaasSecurityManagerBase.authenticate(JaasSecurityManagerBase.java:487) [:3.0.0.Beta4]
        at org.jboss.security.plugins.auth.JaasSecurityManagerBase.isValid(JaasSecurityManagerBase.java:365) [:3.0.0.Beta4]
        at org.jboss.security.plugins.JaasSecurityManager.isValid(JaasSecurityManager.java:160) [:6.0.0.20100721-M4]
        at org.jboss.security.integration.JBossSecuritySubjectFactory.createSubject(JBossSecuritySubjectFactory.java:90) [:6.0.0.20100721-M4]
        at org.jboss.resource.connectionmanager.JBossManagedConnectionPool.testConnection(JBossManagedConnectionPool.java:389) [:6.0.0.20100721-M4]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_21]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_21]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_21]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21]
        at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) [:6.0.0.Beta5]
        at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) [:6.0.0.Beta5]
        at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) [:6.0.0.Beta5]
        at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:271) [:6.0.0.Beta5]
        at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:670) [:6.0.0.Beta5]
        at org.jboss.system.microcontainer.ServiceControllerContext.invoke(ServiceControllerContext.java:194) [:2.2.0.Alpha10]
        at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:61) [jboss-kernel.jar:2.2.0.Alpha10]
        at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus$1.dispatch(LifecycleAwareKernelBus.java:58) [jboss-kernel.jar:2.2.0.Alpha10]
        at org.jboss.kernel.plugins.registry.basic.BasicKernelBus.execute(BasicKernelBus.java:71) [jboss-kernel.jar:2.2.0.Alpha10]
        at org.jboss.kernel.plugins.registry.basic.LifecycleAwareKernelBus.invoke(LifecycleAwareKernelBus.java:57) [jboss-kernel.jar:2.2.0.Alpha10]
        at org.jboss.profileservice.management.KernelBusRuntimeComponentDispatcher.invoke(KernelBusRuntimeComponentDispatcher.java:85) [:0.1.0.Alpha1]
        at org.jboss.profileservice.plugins.management.util.AbstractManagedComponentRuntimeDispatcher.invoke(AbstractManagedComponentRuntimeDispatcher.java:135) [:0.1.0.Alpha1]
        at org.jboss.profileservice.management.DelegatingComponentDispatcherImpl.invoke(DelegatingComponentDispatcherImpl.java:93) [:0.1.0.Alpha1]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_21]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_21]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_21]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21]
        at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:121) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82) [:1.0.1.GA]
        at org.jboss.profileservice.remoting.ProfileServiceInvocationHandler.invoke(ProfileServiceInvocationHandler.java:99) [:6.0.0.20100721-M4]
        at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:898) [:6.0.0.20100721-M4]
        at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106) [:6.0.0.20100721-M4]
        at org.jboss.remoting.Client.invoke(Client.java:1961) [:6.0.0.20100721-M4]
        at org.jboss.remoting.Client.invoke(Client.java:804) [:6.0.0.20100721-M4]
        at org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60) [:1.0.1.GA]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.aspects.remoting.MergeMetaDataInterceptor.invoke(MergeMetaDataInterceptor.java:74) [:1.0.1.GA]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65) [:1.0.1]
        at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102) [jboss-aop.jar:2.2.1.Alpha3]
        at org.jboss.aop.generatedproxies.AOPProxy$1.invoke(AOPProxy$1.java) [:]
        at org.jboss.profileservice.management.client.ManagedOperationDelegate.invoke(ManagedOperationDelegate.java:63) [:6.0.0.20100721-M4]
        at org.rhq.plugins.jbossas5.ManagedComponentComponent.invokeOperation(ManagedComponentComponent.java:218)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_21]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_21]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_21]
        at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_21]
        at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_21]
        at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_21]
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_21]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_21]
        at java.lang.Thread.run(Thread.java:619) [:1.6.0_21]

How can I get rid of this exception and stack trace?  I've already secured the JMX Console and JMX Invoker, but it didn't have any effect.

[thunder.farmer]

to me the exception has nothing to do with datasource config. Seems caused by JBoss SX.

[fibber]

It seems to be a problem with the testConnection() method in org.jboss.resource.connectionmanager.JBossManagedConnectionPool because that's where the stack trace is pointing:

@ManagementOperation(description="Test if a connection can be obtained",
          impact=Impact.WriteOnly)

    public boolean  testConnection()
    {
       boolean result = false;
       ConnectionListener cl = null;

       // first try to get connection with Subject
       if (poolingStrategy instanceof BasePool)
       {
          BasePool basePool = (BasePool)poolingStrategy;
          if (basePool.clf instanceof BaseConnectionManager2)
          {
             try {
                BaseConnectionManager2 baseConnectionMgr = (BaseConnectionManager2)basePool.clf;

                // This is the line that is throwing the exception

                Subject subject = baseConnectionMgr.getSubjectFactory().createSubject(baseConnectionMgr.getSecurityDomainJndiName());

                result = internalTestConnection(subject);
             }
             catch ( Exception ignored )  // createSubject could throw security exception, ignore it
             {
             }
          }
       }

       // then try to get connection without Subject
       if (!result)
       {
          result = internalTestConnection(null);
       }

       return result;
    }

Although I don't know why ignoring a security exception is a good thing, I find it strange that the exception is logged before being thrown - not always the best practice.  In any event, I'd like to know why this exception is occurring and how to get rid of it, if possible.  Of course, it's always possible that the answer is that this is simply a manifestation of some sloppiness or defect in the design, and I'll need to ignore exceptions created when I test my Oracle connection.

The reason that I can't currently accept this explanation is that the DefaultDS does not throw the exception when testing its connection, which leads me to believe that there is either something wrong with my Oracle datasource setup, or that the DefaultDS setup includes additional security configurations that I'm not aware of.

[thies1979]

Hi,

I just found a quiet simple work around for this problem.

I simply added the security domain for the jmx-console to the data source:

<local-tx-datasource>

  <jndi-name>...</jndi-name>

  ...

  <security-domain>jmx-console</security-domain>           

</local-tx-datasource>