Weblog for the AMIS Technology corner
Posts tagged Logging
Oracle Diagnostics Logging (ODL) for application development
Jan 12th
Logging is a very important aspect of application development as it offers run-time access to the behaviour and data of the application. It’s important for debugging purposes but also to investigate exception situations on production. The Java developer has a choice between logging frameworks but Log4J is probably the most used one. The usage is quite simple: grab a Logger, e.g. private static Logger log = Logger.getLogger(MyBean.class);, and then use that logger to log the actual message at the required level, log.debug(“This is a debug message”);. To print the logmessages, the Log4J is configured externally with a properties file that defines the location (e.g. console, file, database etc.) and the format of the logmessages. Other logging frameworks, like Java Util Logging, are used in a similar way. It’s actually a good practice to not use Log4J directly, but to use a wrapping or facade framework, that allows switching of the actual logging implementation itself. In the past that would have been Apache Commons Logging (ACL), but now SLF4J is commonly used because it doesn’t have the classloader issues of ACL and it provides some nice message formatting (and performance) features like log.debug(“{} says: This is a debug message”, user.getName());. By the way, the logging usage of Log4J is similar to SLF4J so you can easily switch by only replacing the imports statements. Read the rest of this entry »
ADF 11g : Log Data Manipulation
Jan 6th
Today I had a request to implement a generic logging mechanism for all changes of data (DML) in an ADF application. The log needs to be persisted in a database table. This application uses ADF-Business Components and an Oracle Database. My first idea was to use database triggers for all tables (insert, delete, update for each row) and write the data to a log table. However that was not generic enough because this has to be implemented on every new table. I had to come up with an ADF solution. It’s basic, no rocket science, but useful Read the rest of this entry »
Debug Logging in BPEL using Sensors – Part 1
Jul 22nd
When developing and/or debugging BPEL processes, the Oracle BPEL Console is your best friend. Every change to every variable, every activity that was executed, everything is right there for you to inspect, whether the instance is still in-flight or already completed. But although this sounds like the ultimate debugging tool, I’m sure you’ve noticed like me that when your processes get really big (which they tend to do rather quickly), there’s two reasons why debugging can be difficult. The first is plain and simple “information overload”. If your audit flow contains hundreds of activities and possibly thousands of variable data changes, finding an individual piece of information is not trivial. I find the second reason, however, to be of even more profound impact: the BPEL console will not show you the execution path through your process flow (which would indicate which parts of the code got executed, and which didn’t), but rather it displays a long, sequential list of Activities that were executed. Especially if you have a lot of switch and/or pick statements, and if your code contains loops (in which case each iteration will add all executed Activities to the list), determining “what happened” during execution of your instance from this long, long audit trail might prove a challenge.
In a “mini-series” of Blog entries, I will share a number of techniques that I have used in situations like this, to extract logging/debug information from a BPEL process instance using BPEL Sensors. This first entry will focus on a simple, straightforward form of logging, using a “Variable Sensor” to provide a sort of “management summary” of the execution of a BPEL process instance. 
Read the rest of this entry »
