ad flogging options

8/10/2019 Ad Flogging Options

1/30

1 Copyright 2013, Oracle and/or its affiliates. All rights reserved.


2/30


Real World ADF Design & Architecture Prin

Error and Information Logging


3/30


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


4/30


Program Agenda

Why instrument?

Logging design

Logging and the developer


5/30


Why Instrument Your Applications?

Its 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 cant explain what they are doing in a waythat relates to what youre looking at

Dont remember what they did to cause the error

I didnt do anything

They lie


6/30


Instrumentation Goals

Help the intelligent site admin self diagnose

Good logging should not assume that the reader has

code

Help your support organization make an educa

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 didnt do anything?


7/30

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?

Image: ima


8/30


Program Agenda

Why instrument?

Logging design



9/30


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

ADF Logger

Its part of the framework, no extra libraries, no classloader

Fully integrated with both JDeveloper and Enterprise Manag

Integrates with FMW-wide logging infrastructure (ECID)

Switchable at runtime

Uses java.util.Logging under the covers


10/30


Whats ECID?

Execution Context ID

Unique ID for a particular transaction (e.g. Web Request)

64 bit identifier + SequenceAllows you to

follow the trail

of events in thattransaction

Particularly usefulin SOA

composites

Can correlate to

user via EM


11/30


Programatically Accessing the ECID

Potentially useful in some error messages

Code:

weblogic.diagnostics.context.

DiagnosticContextHelper.getContextId();


12/30


13/30


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]


14/30


Consider the Consumer of Logging / M

Developer

Support

Customer Admin

ERROR APP001: Raise process for King did not compl

CONFIG employee.class: updateSal():Called with params: empId:101, newsal:

WARNING APP101: Raise failed for Employee King, em

salary value passed to raise routine

INFO employee.class: updateSal():

Setting commission to newSal * 0.1

ERROR employee.class: updateSal(): NullPointerExceERROR APP001: Raise process for King did not compl

WARNING APP101: Raise failed for Employee King, empsalary value passed to raise routine

ERROR NullPointerException

ERROR APP001: Raise process for King did not compl


15/30


Logging Rules

Dont over-log, its 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 conssupport document these!

Config / info messages dont need this though

Use guard conditions around complex log statements

E.g. if you use a StringBuilder or call a separate log routine


16/30


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 s

Log at Error or Warning as appropriate

Assume servers will normally be logging at Warning level

Dont 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


17/30


Where to Log?

As mentioned any error condition

Parameters change, logic does not So always log the inputs (and outputs) of significant routine

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 dema

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?


18/30


Examples of Key Log Points

Task flows:

Initializer, Finalizer: Log the parameters / results Error Handler

ADF BC

View Objects: bindParametersForCollection override for bivalues

Application Modules: doCheckout, prepareSession for tunSQL session setup in particular

Good candidates for your super-classes


19/30


20/30


What not to Log?

Be aware that the framework is already instrumented

You may not want to duplicate that at the finest level


21/30

21 Copyright 2013, Oracle and/or its affiliates. All rights reserved.21 Copyright 2011, Oracle and/or its affiliates. All rights reserved.

Any other ideas for good logging points or places

we should not log?

Image: ima


22/30


Program Agenda

Why instrument?

Logging design



23/30


The Other Side of Logging

Well instrumented code can save a lot of time during dev

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

and problems

Great tuning tool

Over execution of code becomes obvious

* However, this is not an excuse for not learning how to use the debugge


24/30

O


25/30


ODL Analyzer in JDeveloper

Can search andfilter by level and

time

Can relate entries

by request and

time

See detail in the bottom pane inc. exceptions passed to the log

F k L i


26/30


Framework Logging

To gain real value, set the following to Config level in the

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=consoleflag

No need to re-start the server


27/30

C l i


28/30


Conclusion

Make logging simple and fun

Use the code templates to cut down onkeystrokes

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

F th R di


29/30


Further Reading

Adventures in logging

https://blogs.oracle.com/groundside/entry/adventures_in_lo

Oracle ADF Developer Guide on OTN

"Testing and Debugging ADF Components"

JDeveloper Code Templates (download)

http://bit.ly/OhEFfJ


30/30


ad flogging options

Documents