cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Mueller (JIRA)" <>
Subject [jira] [Commented] (CB-611) Logging levels
Date Tue, 01 May 2012 22:12:50 GMT


Patrick Mueller commented on CB-611:

bq. log4j 

As someone who has suffered with log4j and it's "successors" over the years, you're not convincing
me.  :-)

I'm still missing some precision here.  What does this mean?

bq. add the missing functionality to the existing class

Do you mean the JS {{console}} object that is currently visible to most every web browsing
widget available?  Or do you mean the "Debug Console" Cordova plugin?

I'm reading what you're saying is that you want to standardize the additional methods/properties
that the iOS version has added to the JS {{console}} object, across all the platforms.  In
which case ...

bq. If we have to add a new class every time something is missing, we will start a path that
has more and more plugins and source files. This is not a good way forward either, since constantly
adding classes will add complexity and more than one way of doing each thing.

I'm not suggesting we add any additional plugins, assuming we re-use or retro-fit the "Debug
Console" plugin.  We don't need an additional plugin or source file to expose methods on an
new JavaScript object.  We're only exposing a new object in JS.

Also, you're already suggesting "more than one way of doing each thing".  My understanding
is that the existing JavaScript {{console}} object actually works in most of the Cordova runtimes,
in various flavors.  Do we really want to "patch" to take into account the
current logging level?  Now you're changing existing behavior!

Here's my suggestion, based on guesses on your use case.

We create a new {{logger}} property on {{cordova}}.  The primary use for this is plugin code,
not "user land" code.  {{cordova.logger}} will have whatever minimal logging level stuff we
need.  We'll rename the "Debug Console" plugin to "Logger", or whatever.

For platforms that do not have a {{console}} object visible in user-land JS, or the one that's
provided is sub-par or non-operational (iOS), provide an implementation of the FireBug Console
API implemented with the new {{cordova.logger}} object.

This leaves us with a portable, common, non-extended {{console}} object for userland JavaScript.
 Something users are familiar with.  They won't be confused when they see our {{console}}
has sprouted new methods.  Nor will they inadvertently leave invocations of this extended
console API in their code, only to find it throws exceptions outside of Cordova.  For plugin
authors who are doing boat-loads of logging and therefore need lots of control, they can use
the {{cordova.logger}} object.

> Logging levels
> --------------
>                 Key: CB-611
>                 URL:
>             Project: Apache Callback
>          Issue Type: Improvement
>          Components: iOS
>    Affects Versions: Master
>         Environment: Run Cordova/PhoneGap with Cordova-SQLitePlugin and some other plugins
>            Reporter: Chris Brody
>            Assignee: Shazron Abdullah
>             Fix For: Master
>   Original Estimate: 48h
>  Remaining Estimate: 48h
> I got a pull request on my Cordova-SQLitePlugin with a special logging function that
is only logging when built as a debug version. I believe this issue should be solved in the
core with a log function that is only logging when built as a debug version. Ideally a logging
facility with multiple log levels. Please forgive me if this has already been done somewhere.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message