如何从数据源连接确定有关WebLogic数据源的信息？

Question

I have a Spring app running in WebLogic. In my DAO, it inherits a base class with a method that returns a "javax.sql.DataSource". I inject that datasource indirectly using the "jee:jndi-lookup" in my Spring application context to get the datasource from JNDI. When I look at this in the debugger, it appears to be a "weblogic.jdbc.common.internal.RmiDataSource".

I'd like to figure out how I can introspect into that datasource in my code to determine information about the database I'm connected to, particularly the host, port, SID, and username. Is there any way I could do that?

For some background, I have extensive diagnostics in my app for troubleshooting db connection and query issues. It would be very helpful if at runtime, I could introspect information about the WebLogic datasource from the database connection in use.

As I described, I already determined in the debugger what the actual type was, and I've examined all the obvious properties in that object for casting or reflection opportunities, and I don't see any obvious indications of information like "host", "port", or "SID".

Answer 1

I think you can use reflection and call all the getter methods of this class.
That should get you some helpful information. But based on the name of this class,
it looks like it's an internal WebLogic class and it's not really designed for this.
Still, you can do it with reflection, you can even call private getter methods with reflection.

Java Reflection API

Answer 2

The "right" JEE approach is not caring about these low-level details in code. After finding out which DataSource doesn't work, troubleshooting problems involves only application server logs and application server configuration tweaks.

There are several good reasons for insulating applications from DataSource details:

• you aren't supposed to lose track of what abstract data sources you are using; using more than one DataSource (in fact, more than one Connection) in the same class is extremely unusual.
• permanent data source configurations have been defined by you in your application server configuration, they are not secret or hidden.
• transient data source state, on the other hand, is accessible through application server tools and logs.
• on the third hand, data source implementations are proprietary and need to be freely optimized; expecting them to provide useful information is unreasonable.
• your application is unlikely to be able to fix a troublesome data source; if it could, it would be able to mess with other applications in the same application server.
• "replacing" a data source with another doesn't make any sense.
• any scenario in which you want the definition of data source to vary according to circumstances should be dealt with by other means, mostly close to the DBMS (for example, if DBMS processes or machines are subject to shutdowns and restarts you could configure the servers as a cluster sharing the same IP address; relatively easy with Oracle).