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

[GoogleCodeExporter]

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 reported on code.google.com by dwich...@gmail.com on 11 Jul 2010 at 4:12

[GoogleCodeExporter]

Original comment by manico.james@gmail.com on 11 Jul 2010 at 7:53

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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).

Original comment by manico.james@gmail.com on 11 Jul 2010 at 7:53

[GoogleCodeExporter]

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

Original comment by manico.james@gmail.com on 2 Nov 2010 at 8:02

• Added labels: Milestone-Release2.1