enterprise library - Logging Application Block - Priority, Category values -

i looking best practices regarding usage of enterprise library's logging application block , priority, category , severity values 1 should use.

when comes severity, answer quite simple: use 1 of system.diagnostics.traceeventtype enums.

but priority int , category array of strings. not sure best practice when comes these 2 values....

here 2 schemes have come when comes category:

1. use class name category
2. use predefined category different types of messages except application (eg: exception, information, etc...).

advantage of 1: allows give great control on classes want logging @ given point. (specify class name , severity control logged , logged).

disadvantage of 1: can unwieldy, may have 100s of categories , there no easy way setup configuration capture exceptions in application.

advantage of 2: exact opposite of 1, makes real easy specify want exception messages go , allows turn off logging of unnecessary information.

disadvantage of 2: not configurable (1).

looking other ideas when comes priority , category.

but priority int , category array of strings. not sure best practice when comes these 2 values....

in terms of priority recommend not using priority unless have specific requirement log based on priority. if don't explicitly need priority causes more headaches it's worth.

here 2 schemes have come when comes category:

1. use class name category
2. use predefined category different types of messages except application (eg: exception, information, etc...).

in experience above 2 options common choices. but why choose? since (as mention) can have more 1 category there no reason choose 1 on other. if wish, can have multiple categories , enable ones interested in @ time.

for example, in addition adding class name (mycompany.businesslogic.processor) category add namespace or assembly name category (mycompany.businesslogic).

other categories consider adding categories functional area or application layer. e.g. "dataaccess" or "ui".

i think if use both of approaches list should cover situations. enable "exception" , if need more granular logging turn information on specific classes or enable information globally.