If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Consolidate logging, support fine-grained logging

NEW
Unassigned

Status

Calendar
General
--
enhancement
9 years ago
6 years ago

People

(Reporter: dbo, Unassigned)

Tracking

Details

(Reporter)

Description

9 years ago
We currently have at least two logging mechanisms in the code:
- calUtils.js' function LOG()
- calWcapUtils.js' function log()

Moreover we've more and more code logging, bloating the console if calendar.debug.log or calendar.debug.log.verbose is set. This makes it increasingly harder to read the log.

I think we need to
- consolidate and find a new API
- have a look at what stock mozilla platform offers
- add support for scoped/fine-grained logging, i.e. that users can switch on logging for specific code areas only, like e.g. "itip, wcap".
- add support for file logging (wcap's logging code may be recycled)
Flags: wanted-calendar1.0+
(Reporter)

Comment 1

9 years ago
- add support for different log levels, e.g. from 1 (basic) to 5 (verbose) like "itip:5"
See bug 451283 and 450631.  We're planning on having log4moz available as part of Thunderbird, either as part of log4moz in toolkit or in mailnews.
adding dmose, because i know he cares.
(Reporter)

Updated

9 years ago
Depends on: 450631
OS: Mac OS X → All
Hardware: x86 → All
Flags: wanted-calendar1.0+ → blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]

Comment 4

6 years ago
I don't think this is a 1.0 blocker.
Agreed, not that important!
Flags: blocking-calendar1.0+
Whiteboard: [not needed beta][no l10n impact]
If this should be of use for calendar and its providers this should depend on bug 451283, shouldn't it?
Calendar is not only used in Thunderbird/Lightning but also in Seamonkey and probably others.
You need to log in before you can comment on or make changes to this bug.