Dynamically enabling (or disabling) the JDBC driver level logging using debug version of Oracle JDBC thin driver (ie ojdbc6_g.jar) on app server

This post is about dynamically enabling (or disabling) the  JDBC driver level logging with debug version of Oracle JDBC thin driver "ojdbc6_g.jar" in place while app server is up and running.

Typically, when this jar is put in place in application server environment, we enable the logging using JAVA system property "-Doracle.jdbc.Trace=true". This approach is static in the sense that application server restart is needed each time we want to enable or disable the logging. This static approach is not at all feasible in a production system where we want to trace the jdbc calls at some particular instance of time.

A programmatic (dynamic) approach to enable/disable driver level logging is also discussed in doc "http://docs.oracle.com/cd/B28359_01/java.111/b31224/diagnose.htm". However this approach is suitable for enabling/disabling the logging from within the application. So this method would essentially only trace JDBC calls at places where application code interacts with DB which might not be sufficient to troubleshoot jdbc issue in application server environment where jdbc connections are actually maintained and managed by application server.

Extending this dynamic enabling/disabling logging idea to application server is a bit tricky. From application server perspective, we can toggle driver level logging at runtime using similar programmatic approach. This would affect the logging at global level (be it app server interactions with DB or any application that is deployed on the app server, all DB interactions would be logged). This can be accomplished on " sun.misc.Launcher$AppClassLoader" instance that lies at "com.oracle.jdbc"/"diagnosability" in MBean tree.

Steps
======
A) Grab the instance name of MBean "com.oracle.jdbc"/"diagnosability" using JConsole, or any other JMX browser utility.

How:
1. Start JAVA_HOME/bin/jconsole or jvisualvm
2. Connect to app server process where logging needs to be enabled/disabled
3. Goto MBeans tab
4. Expand "com.oracle.jdbc"/"diagnosability"
5. Select the available MBean
6. Get the name portion from field "ObjectName" (this would be the loader string, as referenced in sample code here  .

For example, if we have:
  ObjectName="com.oracle.jdbc:type=diagnosability,name=sun.misc.Launcher$AppClassLoader@601bb1"

Then loader would be "sun.misc.Launcher$AppClassLoader@601bb1"


B) Target the sample application "JDBCDriverLogger.war" (download from here ) to the application server instance on which you want to enable/disable the driver logging.

C) Create a logging configuration, say "myConfig.properties"

######snippet from myConfig.properties - starts##########
.level=FINER
oracle.jdbc.level=FINER
oracle.jdbc.handlers=java.util.logging.FileHandler
java.util.logging.FileHandler.level=FINER
java.util.logging.FileHandler.pattern=d:\\jdbc.log
java.util.logging.FileHandler.count=1
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
######snippet from myConfig.properties - ends##########


D) set the JAVA System property to point to logging configuration file:
         set JAVA_OPTIONS=-Djava.util.logging.config.file=myConfig.properties


E) Restart the application server if necessary. Note this restart might be needed to pickup  file "myConfig.properties" and is one time activity. If this file is already available to the application server, then no need to restart.


F) hit the application on application server instance:
    http://soa_server1ip:port/JDBCDriverLogger/loggerControl.jsp


The IP and Port in above URL will correspond to the app server instance where logging needs to be enabled/disabled, and where the applicaton "JDBCDriverLogger.war" was targetted previously

G) Enter loader name (obtained from step A6) in the text field next to "Enter ClassLoader Object instance name:" on the JSP page, and hit "EnableLogging"

This would enable driver level logging on app server instance

H) to disable the logging, enter the same loader name in the text field next to "Enter ClassLoader Object instance name:" on the JSP page, and hit "DisableLogging"



Ref:
http://docs.oracle.com/cd/B28359_01/java.111/b31224/diagnose.htm

Comments

Post a Comment

Popular posts from this blog

Replacing expired certificates on SSL Server that uses JKS based keystore

Replacing an expired identity certificate in a JKS based keystore is pretty easy stuff, unless you have forgot to keep a backup of your private key. This post discusses the use-case where we don't have a backup copy of the private key outside the JKS keystore, and we wish to replace the expired/going-to-expire identity certificate There are two ways that I know of: Portecle (easy) - this is a tool available out on internet OpenSSL-Keytool combination (lengthy one) I will discuss 2nd one, and would only provide commands (and not discuss each switch as you can always refer relevant product docs for it) 1. Backup the JKS keystore, suppose original is  "keystore.jks" 2. JKS -> PKCS12 conversion (pkcs12 obtained in this step would be run through OpenSSL in next step, to separate the private key from the expired certificates)          keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12 -srcstoretype JKS -deststoretype PKCS
Read more

Giving non-admin users the permission to access MBeans

Sometimes it might be a requirement that a JEE application, deployed on WebLogic, needs an access to MBeans (Server, domain  or custom MBeans). With WebLogic default administrator user and other users who belong to default administrator group “Administrators” such a thing is possible quite easily. However it is not a good practice as the admin credentials would unnecessarily get exposed to application (and it may in-turn have security consequences). So, the question comes up - can we avoid using these admin credentials and instead use appropriate credentials, in our application, based on role access? The answer is yes - this requirement involves working with JMX policies. WebLogic provides a way for creating new as well as modifying existing (default) JMX policies. So what you can do is use the JMX policy editor to grant non-admin user/group a write access to the required MBean. JMX policy editor is described here . Also refer this to enable the JMX policy editor if it i
Read more

Modifying the "supported" attributes of embedded ldap users/groups

Image
WLS Admin console provides limited access to modify the attributes of users and groups that are located in its embedded ldap. This is primarily because embedded ldap is not supposed to hold any application users/groups on a large scale and probably this is one of the reasons why WLS does not provide any dedicated GUI to to modify the user/group attributes inside embedded ldlap. Neverthless, we can store these users/groups and we can modify the attributes as well. There are two approaches: 1) Using an external LDAP browser utility . My favorite as of today is jxplorer . I use such a utility against WLS embedded ldap for various purposes - testing the connectivity, the bind operation, search queries, etc Using such ldap browser utilities against WLS embedded ldap requires one to explicitly open embedded ldap for "outside WLS" access.This involves resetting the password of embedded ldap's super user "Admin" to a known value. Note that when WLS domain is creat
Read more