Oracle Diagnostic Logging - getting deeper into OIM11gR2

Going deeper into OIM is a little different using ODL instead of the old log4j.properties file in OIM 9.1.0.2

If you have read my previous post on how to set up and hand modify the ODL files for your server, you will be able to perform these tasks.

Here are some interesting logging points I have tried:

  <logger name='oracle.iam.provisioning' level='TRACE:32'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='oracle.iam.identity' level='TRACE:1'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='Thor.API.Operations' level='TRACE:32'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='XELLERATE.DATABASE' level='NOTIFICATION:32'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='XELLERATE.SERVER' level='NOTIFICATION:1'>
   <handler name='odl-handler'/>
  </logger>
  <logger name='XELLERATE.SCHEDULER' level='NOTIFICATION:1'>
   <handler name='odl-handler'/>
  </logger>
 
The handler name was changed back to odl-handler, but I use my own handler that segregates the parts I am interested in.  I put all of the parts I am interested in, into a handler I call edu-handler, so in my logging.xml file, all of the above odl-handler references actually are edu-handler.  I just want someone who wants to copy/paste to not have a failure because they haven't defined an edu-handler.

Packaging an incident report on a weblogic managed server

How to package an incident report:

View this URL:

http://docs.oracle.com/cd/E27559_01/core.1112/e28516/diagnostics.htm#ASADM11171

Quick setup:

Here is a little script to list the OIM incidents (for OIM):

#!/bin/sh
# Lists time and problem for incidents on OIM
PWD=`pwd`
now=`date`
tf=/tmp/litmp$$
cd $DOMAIN_HOME/servers/oim_server*/adr/diag/ofm/oim_domain/oim_server*
echo "Searching incident reports"
find incident/ -type d -name 'incdir_*' -print > $tf
for each in `cat $tf`
do
  echo " "
  head -4 $each/readme.txt
done

Find the incident you want.

Have this script setenv_adr handy and source it:

ORACLE_HOME=$MW_HOME/wlserver_10.3/server/adr
export ORACLE_HOME
LD_LIBRARY_PATH=$ORACLE_HOME
export LD_LIBRARY_PATH
PATH=$PATH:$ORACLE_HOME

Next run adrci and copy in the following:

SET BASE <use your MW_HOME folder>/user_projects/domains/oim_domain/servers/oim_server1/adr
SET HOMEPATH diag/ofm/oim_domain/oim_server1

Of course use your own folder names and server names.  Then enter:

IPS CREATE PACKAGE INCIDENT incident_number

IPS ADD FILE filespec PACKAGE package_number 

IPS GENERATE PACKAGE # in /tmp

Working with the Oracle Diagnostic Logging on Weblogic

How to use the ODL effectively in the following:

Event Handlers
Scheduled Tasks
ICF Connectors

First, use the following classes in your code:
java.util.logging.Logger
java.util.logging.Level

You do not have to use log4j-xxx.jar it is not needed.

Second, and this is very important, if you CAN, do not begin your package name with com, rather use something unique like edu for colleges or your company abbreviation.  This will make it easier to do the configuration in the Enterprise Manager.

Next, in your code, use the following techniques:
1) In your class definition, create a private static final Logger called logger and initialize it with the class like this:
private static final Logger logger = Logger.getLogger(MyClass.class.getName());

2) In each method specify a String with the method name such as:
String methodName="execute";

3) At the beginning of each method use:
logger.logp(Level.FINE, getClass().getName(), methodName, "Entering");

4) Optionally, at the end of each method use:
logger.logp(Level.FINE, getClass().getName(), methodName, "Exiting");


5) For the rest of your output statements, use:
logger.logp(Level.FINE, getClass().getName(), methodName,
   "whatever you want to say in your message");

For these types of statements the following are available:
Level.SEVERE         Level.WARNING      Level.INFO
Level.FINE               Level.FINER             Level.FINEST

That's it for the code.

In Weblogic's Enterprise Manager, open the deployment where you have placed your code, Nav to this with WebLogic Domain -> domain name and select the managed server.

You will see the managed server name (it needs to be up with the green up arrow) and below that will read WebLogic Server and show a down arrow.  Select the down arrow and nav to Logs -> Log Configuration.

In here you see 3 tabs, Log Levels, Log Files, and QuickTrace.  Select Log Levels, View Runtime Loggers, and search on your class name.

Find your class name.  The default log level is normally WARNING.  Choose wisely the class or package you want to modify, and set the level to the highest level you wish to see.  Scroll to the bottom of the screen and check the "Persist log level state across component restarts" and then click "Apply".  Your logger is now set to go to the diagnostic.log file.

If you want to have your data go to a separate set of log files, go to the Log Files tab and select the odl-handler Handler Name, then click on "Create Like...", and create a new Handler.  Give it a cool name and change the configuration to use a different file name pattern than -diagnostic.  Save this and then assign your classes to it.  Done.

Reduce Weblogic startup time

This one is from my coworker:

In the jre/lib/security/java.security file for the JDK you are running WLS under look for this line:

securerandom.source=file:/dev/urandom

and change it to:

securerandom.source=file:/dev/./urandom

It cuts the startup time in half.  It has to do with a bug where Java interprets /dev/urandom as /dev/random which is a really slow RNG in Linux.  Adding the /./ reference is a simple workaround and makes it go back to /dev/urandom as the RNG.

SSL Keytool Mojo

Keytool setup: put the following into your .bash_profile:

JAVA_KEYSTORE="-keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit"

DEMOTRUST_KEYSTORE="-keystore $WL_HOME/server/lib/DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase"

This will make it easy to use keytool.  Then you can do:

keytool -list $JAVA_KEYSTORE

keytool -list $JAVA_KEYSTORE | grep rootca

keytool -delete -alias rootca $JAVA_KEYSTORE

keytool -import -alias rootca -file <filename> $JAVA_KEYSTORE