Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 3DEAB9F92 for ; Tue, 1 May 2012 22:13:12 +0000 (UTC) Received: (qmail 53248 invoked by uid 500); 1 May 2012 22:13:12 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 53214 invoked by uid 500); 1 May 2012 22:13:12 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 53206 invoked by uid 99); 1 May 2012 22:13:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 May 2012 22:13:12 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 May 2012 22:13:10 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 8654542A433 for ; Tue, 1 May 2012 22:12:50 +0000 (UTC) Date: Tue, 1 May 2012 22:12:50 +0000 (UTC) From: "Patrick Mueller (JIRA)" To: callback-dev@incubator.apache.org Message-ID: <1579267483.15153.1335910370569.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <1987883416.12790.1335863931472.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (CB-611) Logging levels MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/CB-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266188#comment-13266188 ] 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" console.info() 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: https://issues.apache.org/jira/browse/CB-611 > 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira