Open UI: SiebelJS.Log & The Stack


SiebelJS.Log allows the developer to debug the application by writing to the browser console. This has been provided since

Most modern browsers have console.log which performs the same function, except console.log causes an error in IE if the developer toolbar has not already been opened. SiebelJS.Log avoids this problem by first checking if the console object is available, before calling the log method.

SiebelJS.Log is better for this reason.

SiebelJS.Log in

In Oracle changed the way SiebelJS.Log works.

SiebelJS.Log no longer supports a string argument, but rather an Error object. This also means all previous log statements from will be ignored silently.

Update: The above behaviour affects the only the sample application. SiebelJS.Log has been redefined in to support an Error object, but passing in a String will still log to the console. Usage
TestPRList.prototype.ShowUI = function(){

function hello_a(){
function hello_b(){
function hello_c(){
    SiebelJS.Log( new Error('Error occurred here')) ;


Notice that it produces an error message with a stack trace.

If you don't like the stack trace produced by SiebelJS.Log, you can call SiebelJS.Trace or console.trace directly to produce a stack trace without the error message.

Just substitute SiebeJS.Log with console.trace in the above example. This results in a much cleaner output as can be seen below.

console.trace is supported in Chrome, Firefox, and Opera.


Although there has been no official documentation page on the SiebelJS class and its available methods, it has been used in Oracle Bookshelf alongside usage examples of other methods, and as such, can be considered to be implicitly documented.

For better or for worse SiebelJS.Log has been redefined to be used as an error logger. Open UI customers that need a method for logging, are better off creating a wrapper around console.log, and put it in a client side library (if you haven't already done so). brings many changes, including unspecified changes to the browser API. Customers that are upgrading from, will find that customizations don't port over without some rework.

The temptation to use undocumented methods is ever present, because the source code is more readable than the documentation. This serves as a good reminder for us to avoid using undocumented methods, or at least have a good mitigation strategy if you do use them.


Post a Comment

Comments are open to all, please make it constructive.