94480 - Add a logging service to supercede nspr and xpcom logging

Status: RESOLVED DUPLICATE of bug 881389

(Core :: XPConnect, enhancement)

Description

[Axel Hecht]

NSPR logging doesn't always cut it. And XPCOM logging is rather dead by now.
dmose and I have been chatting, so here is a bug to store the ideas, so they 
don't get lost at all.

Dan wanted to have a logging facility which would allow to get messages to
both the log, and to the console service. It should be easier to use than the
console service alone.

It would be nice to use the log from js, so this is a higher level than xpcom
or nspr (xp apps).

How about a service for each log, with a contract IDs like 
@mozilla/log;1?name=my-foo-log

The idl should have methods for messages and debug logging, so that debug blurb
can be optimized out, and messages still make it to the console service.

The logs should support a level of detail, too. And having a contract ID for 
each log would even allow a UI for setting the log parameters, like output,
level of detail and such. Even dynamically.

The signature should be the same for both debug and non debug builds, but 
non-debug builds should get a (at least almost) zero cost implementation.

So much off my head

Axel

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

Other features I'd like to see:

* It would be nice to be able to put this stuff to stderr if desired by setting
one more env vars.

* It should have log levels like PR_Log and friends have, but with much more
granularity (ie many more than 5 levels).  Or maybe just adding sublevels to the
NSPR stuff would be sufficient.

Perhaps this can be built based on the existing (but not used much) xpcom
logging stuff that warren wrote, or perhaps on NSPR logging.

Can anyone that I've just CCed comment on what the last known state of the
nsLogging stuff is?  I seem to remember dbaron ultimately backing warren out,
but my memory may be fuzzy.

Comment 2

[Brendan Eich [:brendan]]

Let's get warren to do it!  Oh, wait...

Cc'ing neo-warren. ;-)

/be

Comment 3

[Chris Waterson]

Ugh. This was _such_ a disaster last time. Please don't invent an
all-singing-all-dancing logging service again. I'll throw up. And don't try to
#define away printf().

So...

- What's wrong with |dump()| from JS?

- NSPR logging sends stuff to stderr if you don't specify the NSPR_LOG_FILE
  environment variable.

- You can hack the NSPR log level to mean whatever you want. If you want it
  to be bit-flags, let it be bit-flags. See nsHTMLContentSink.cpp for an
  example of this.

Comment 4

[timeless]

for javascript dump() in pac we're suggesting using the JavaScript console 
instead of the text console, if it's a success it might be suggested for 
javascript dump() in general

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

FWIW, Warren's stuff is still in the tree to some extent (it's used in one
place, so bug 58966 still clutters up the leak stats).  I wanted to back it out
(I can't find the bug right now), but someone (can't remember who) said he
wanted to clean up Warren's stuff and get it used.  (Warren apparently had a
branch with it significantly cleaned up ready to land the day he left Netscape.)

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

warren's branch was logging_102900_branch, and it was Darin who seemed
interested in reviving warren's nslog.h the last time this was discussed. 
(That's actually from an email thread I have archived, not a bug.)

Comment 7

[Darin Fisher]

I'm actually far less keen on warren's logging branch now then i used to be ;-)

I don't see any _real_ problems with NSPR logging, and the effort involved in
changing things probably isn't worth the time IMO.  So, I have no objections if
you want to remove any last vestiges of warren's logging code.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: quick attempt at patch to remove Warren's logging stuff from the build [Checkin: Comment 14]

Comment 9

[Axel Hecht]

Hrm. Just removing warrens logging is not the right thing. There are obviously
a few places in the code that use that logging (or intend to), so they should
at least get a chance to move to some other stuff, before you just prune the
places they wanted to log.

Axel

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

As far as I know, there is only one PRINTF in the tree, and that's the one
removed above in nsAtomService.cpp.  The above patch does compile -- there were
a bunch of other places that declared logs but didn't use them.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Pavlov and I have both recently run into the problem that one can't use pr
logging in a header that's included in nsXPComInit.cpp due to nslog.h.  Anybody
want to review attachment 45614 [details] [diff] [review]?

Comment 12

[Stuart Parmenter]

Comment on attachment 45614 [details] [diff] [review]
quick attempt at patch to remove Warren's logging stuff from the build
[Checkin: Comment 14]

r=pavlov

Comment 13

[Darin Fisher]

Comment on attachment 45614 [details] [diff] [review]
quick attempt at patch to remove Warren's logging stuff from the build
[Checkin: Comment 14]

sr=darin (looks good)

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

OK, it's out now, although the files aren't removed yet (I filed bug 107510 to
give people a chance to object, although I hope nobody does).  However, after I
checked in I found out that some of that addressbook code (which I now know is
only built on Windows) really was using the XPCOM logging stuff, and I had to
convert it to NSPR logging.  It wasn't as bad a landing as when it was landed
initially, though. :-(

Comment 15

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 16

[Andrew Schultz]

Is anyone still interested in this?

Comment 17

[Darin Fisher]

I am, but how about just providing a XPCOM interface to NSPR logging?  Do we
really need to unify console logging and "NSPR-style" logging?  NSPR logging is
pretty nice, and with support from preprocessor.pl, we could probably come up
with a similarly nice solution for logging from JS that could be conditionally
compiled out.

Comment 18

[timeless]

i have that, it's stuck waiting for wtc to accept patches to nspr. pushing is
welcome.

Comment 19

[Dan Mosedale (:dmosedale, :dmose)]

darin: I don't think we want something that conditionally gets rid of this
logging at build time, since it'll often be useful to sysadmins and extension
authors trying to use regular builds.  Better might be a pref to make
spidermonkey ignore this when it compiles JS, perhaps.  Changing the pref would
have to blow away any fastload files, I assume.

Comment 20

[Darin Fisher]

Our JS files pass through preprocessor.pl, so it is incredibly trivial to
implement conditionally included code in the JS files.  There are times when you
want increased amounts of debugging in a debug build (maybe inside some loop
body) that would be cost prohibitive in a release build.  Giving component
authors the ability to optionally define FORCE_PR_LOG (or some equivalent) in
Makefile.in should be sufficient to allow logging to remain in release builds. 
This is what we do for C++ logging, and it works well there.  Why not go with
something similar for JS?

Comment 21

[Dan Mosedale (:dmosedale, :dmose)]

Assigning bugs that I'm not actively working on back to nobody; use
SearchForThis as a search term if you want to delete all related bugmail at
once.

Comment 22

[Eric Rahm [:erahm]]

The latest attempts at improved logging are being tracked in bug 881389.