Ceki's definition of the problem meets my practical concerns and so I am happy to run with it. Clearly Ceki wishes to reduce the scope of the problem - I quite agree that this should be done. I wouldn't want to do this as part of the problem definition myself because I would consider that to be second guessing the eventual form of the answer. For example I would be surprised if backward compatability for the Priority class was particulary important - I never use it personally but I may be an atypical user.
For the record here is a reasonably concise and hopefully precise problem definition that I prefer because I think it gives you more options. Problem definition: As a library vendor I cannot code against log4j without strong guarantees of binary compatability between versions. I would like an API that I can code against without the danger of binary incompatability. This API should meet the following minimal requirements: 1) I should be able to log at different priority levels. 2) It should be possible to categorize log statements in some way 3) Logging should not have an undue impact on performance 4) I should be able to flexibly filter logging output at runtime. 5) Writing log statements should not require significantly more code than using System.out for logging. 6) End users should be able to redirect the output in a flexible way. The more additional requirements this API meets the better. John -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
