Oracle ADF Architecture TV - Development - Logging

Real World ADF Design & Architecture Principles
Error and Information Logging
ORACLE
PRODUCT
LOGO
15th Feb 2013 v1.0

Learning Objectives
•  At the end of this module you should be able to:
–  Understand logging in Oracle ADF
–  Know when to log and when to log
–  Know how to read and analyze ADF logs
Image: imagerymajestic/ FreeDigitalPhotos.net

Program Agenda
•  Why instrument?
•  Logging design
•  Logging and the developer

Why Instrument Your Applications?
•  It’s a great debugging aid for development
–  But that is not the primary goal
•  The dirty truth about end users:
–  Use the application not your code –
• They can’t explain what they are doing in a way
that relates to what you’re looking at
–  Don’t remember what they did to cause the error
• “I didn’t do anything”
–  They lie

Instrumentation Goals
•  Help the intelligent site admin self diagnose
–  Good logging should not assume that the reader has the source
code
•  Help your support organization make an educated guess
–  Log messages are great search terms
•  Help developers focus on the likely cause
–  “How on earth is that parameter null….?”
–  “What did you do before you didn’t do anything?”

7 Copyright © 2013, Oracle and/or its affiliates. All rights reserved.7 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.
Wouldn't it be best to log everything that happens
within an application to leave fine traces of what
happens in case things go wrong?

Program Agenda

Why use the ADF Logger?
•  System.out.println is not a logger!
–  Cannot be switched off, filtered or easily captured
•  Many Java logging implementations exist but you should use the
ADF Logger
–  It’s part of the framework, no extra libraries, no classloader issues
–  Fully integrated with both JDeveloper and Enterprise Manager
–  Integrates with FMW-wide logging infrastructure (ECID)
–  Switchable at runtime
–  Uses java.util.Logging under the covers

What’s ECID?
•  Execution Context ID
–  Unique ID for a particular transaction (e.g. Web Request)
•  64 bit identifier + Sequence
–  Allows you to
follow the trail
of events in that
transaction
–  Particularly useful
in SOA
composites
–  Can correlate to
user via EM

Programatically Accessing the ECID
•  Potentially useful in some error messages
•  Code:
weblogic.diagnostics.context.
DiagnosticContextHelper.getContextId();

Integration with Enterprise Manager

Using the Logger
•  However, logging needs a degree of design
•  Consider
–  Placement
–  Message Level (use Config, Info, Warning, Error)
–  Detail / content
–  Message consumers [User Admin | Support | Developer]

Consider the Consumer of Logging / Messages
Developer
Support
Customer Admin
ERROR – APP001: Raise process for King did not complete
CONFIG – employee.class: updateSal():
Called with params: empId:101, newsal:<null>
WARNING – APP101: Raise failed for Employee King, empty
salary value passed to raise routine
INFO – employee.class: updateSal():
Setting commission to newSal * 0.1
ERROR – employee.class: updateSal(): NullPointerException
WARNING– APP101: Raise failed for Employee King, empty
salary value passed to raise routine
ERROR – NullPointerException

Logging Rules
•  Don’t over-log, it’s not a code coverage tool
•  Log message translation is possible but not necessary
•  Think about supportability
–  Assign error/warning codes to help in search, aimed at consumers and
support – document these!
–  Config / info messages don’t need this though
•  Use guard conditions around complex log statements
–  E.g. if you use a StringBuilder or call a separate log routine

Logging Rules continued
•  Use per-class loggers rather than a single utility* class
–  More granularity of control and filtering
•  Always log exceptions – even when a message is also sent to the UI
–  Log at Error or Warning as appropriate
–  Assume servers will normally be logging at Warning level
•  Don’t use logging as an audit
–  The app server administrator can switch it off
*NOTE: Bug 14283664 SOURCE CLASS AND METHOD ARGUMENTS PASSED TO ADFLOGGER METHODS ARE IGNORED

Where to Log?
•  As mentioned – any error condition
•  Parameters change, logic does not
–  So always log the inputs (and outputs) of significant routines
–  Particularly with re-usable components, e.g. Task Flows
•  State changes are interesting, steady state is not
–  State dumps could be a “special feature” executed on demand rather
than every time (beware of security concerns though)
•  Be cognizant of the number of times it will be invoked
–  e.g. Is a lifecycle listener such a good idea?

Examples of Key Log Points
•  Task flows:
–  Initializer, Finalizer: Log the parameters / results
–  Error Handler
•  ADF BC
–  View Objects: bindParametersForCollection override for bind variable
values
–  Application Modules: doCheckout, prepareSession for tuning and PL/
SQL session setup in particular
–  Good candidates for your super-classes

Examples of Key Log Points continued
•  Managed beans
–  Particularly useful in common constructor superclass to help understand
the lifecycle of beans
•  Override DCErrorHandlerImpl to catch ADFm exceptions
•  Timers / Async callbacks
–  Can identify sequence issues not visible in debug environment

What not to Log?
•  Be aware that the framework is already instrumented
–  You may not want to duplicate that at the finest level

Any other ideas for good logging points or places
we should not log?

Program Agenda

The Other Side of Logging
•  Well instrumented code can save a lot of time during development
–  Hot switchable – no need to start and stop the server
–  Faster than stepping through in the debugger*
•  Built-in logging can help with understanding Framework operation
and problems
•  Great tuning tool
–  Over execution of code becomes obvious
* However, this is not an excuse for not learning how to use the debugger properly

•  Add an additional dimension to your guarded log condition to reflect
mode
if (_logger.isLoggable(Level.INFO) &&
context.isDevelopmentMode) {
StringBuilder logMsg =
new StringBuilder("Information:");
logMsg.append(...);
_logger.info(logMsg.toString());
}
Developer v’s Runtime Logging Mode
A pattern to consider

ODL Analyzer in JDeveloper
•  Can search and
filter by level and
time
•  Can relate entries
by request and
time
•  See detail in the bottom pane inc. exceptions passed to the logger

Framework Logging
•  To gain real value, set the following to Config level in the ODL
logging configuration screen:
–  oracle.adf, oracle.adfinternal, oracle.jbo
•  Now you can trace by ADF Request
–  Relate each action to the lifecycle
–  See how long each one takes
–  Observe what gets refreshed / executed
•  Replaces the old –Djbo.debugoutput=console flag
–  No need to re-start the server

ADF Request Tracing

Conclusion
•  Make logging simple and fun
–  Use the code templates to cut down on
keystrokes
•  Install permanent logger for your package root
–  Performance hit not an issue during development
–  Helps you appreciate when you have over-logged
•  Consider lifecycle based logging
•  Learn to use the analyzer

Further Reading
•  Adventures in logging
–  https://blogs.oracle.com/groundside/entry/adventures_in_logging_index
•  Oracle ADF Developer Guide on OTN
–  "Testing and Debugging ADF Components"
•  JDeveloper Code Templates (download)
–  http://bit.ly/OhEFfJ

Oracle ADF Architecture TV - Development - Logging

More Related Content

What's hot

Similar to Oracle ADF Architecture TV - Development - Logging

Recently uploaded

Oracle ADF Architecture TV - Development - Logging