Change ESAPI Logging levels to indicate importance of log event but not indicate success/failure

[meg23]

From dwich...@gmail.com on July 11, 2010 12:12:14

I propose that we change the existing ESAPI Logging call as follows:

Current: fatal --> New: urgent Current: error: --> New: very important – I don’t really like this one by the way. Current: warning: --> New: important Current: info --> New: info (no change) Current: debug --> New: debug (no change) Current: trace --> New: trace (lowest value) (no change) – Jim: "While we are at it, can we change "trace" ? It doesn't imply "less than debug" to me...." Dave: how about 'details' or something like that.

An alternative is to simply get rid of the names altogether and simply have numeric levels, which Log4J already supports under the hood, I think most of the levels just don't have names.

If we did this, we could simply change the API to require the first parameter to be the log 'level' and it would simplify the interface. Then, each application could define constants for those 'levels' to be whatever they want, and our reference implementation could in fact define constants that the developers could use as the 'defaults' but they could ignore them and come up with their own ordering scheme without changing the ESAPI ref implementation at all.

For history, the follwing was my original request:

I would like to propose a change to the ESAPI logging API.

We did the simple thing of adopting similar names that Log4J uses: • fatal (highest value) • error • warning • info • debug • trace (lowest value) However, when you add types of events (Security/Functional) and more importantly (Success or Failure) to the log event, then these methods names are confusing and potentially contradictory.

For example, if you have a successful event that is REALLY important for you to ALWAYS log, then how would you do that?

Well …

Something like: esapi.logger.fatal(SECURITY_SUCCESS, “User just updated the secret formula for Pepsi.”);

And this just seems wrong …

SUCCESS coupled with FATAL doesn’t seem right, or ERROR, or even WARNING. I think we need to change the log levels to indications of importance, but not indications of good or bad.

I don’t think locking in the actual levels, like One, two, three is a good idea as I want to allow for flexibility in inserting new levels in between things as is already allowed by Log4J.

I actually don’t mind the first three levels, trace, debug, info as these don’t seem to imply anything good or bad, but warning, error, fatal don’t seem right. How about something like:

URGENT VERY IMPORTANT IMPORTANT

-Dave

Original issue: http://code.google.com/p/owasp-esapi-java/issues/detail?id=129

[meg23]

From manico.james@gmail.com on July 11, 2010 12:53:15

Labels: -Type-Defect Type-Enhancement

[meg23]

From manico.james@gmail.com on July 11, 2010 12:53:52

From Wichers: I also proposed an alternate idea of completely scrapping (or mostly so) the use of named levels and use a purely numeric level system within ESAPI. This would then allow developers to use a DEFAULT set of levels provided by ESAPI, or come up with their own scheme without having to change any ESAPI ref implementation code. I think I’m leaning towards this approach more.

If we adopted this, we could add just a single logging method and deprecate all the others, which would simplify the API significantly and make it much more extensible (in my opininion).

[meg23]

From manico.james@gmail.com on November 02, 2010 01:02:06

This is still under debate, I think we want to do both - old log4j calls, and the new calls (but not numeric)

Labels: Milestone-Release2.1