But that is not the case - not at all. JSecurity Logging interfaces (all 2 of them + about 5 implementation classes) is far less than SLF4J, which has at last count 46+ interfaces and classes.
Again, I'm talking about a featherweight wrapper - not a full abstraction layer. All I wanted to support out of the box was 3 implementations: A console logger on < JDK 1.3. A JDK 1.4 logger if they don't include any other dependency, and a SLF4J one to handle all other cases. I just love the fact that we wouldn't have forced dependencies. 1 jar. That's just awesome :) On Fri, Jul 11, 2008 at 12:23 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: > I feel that we might be moving to a consensus that > > JSecurity Logging API == SLF4J Logging API > > functionality wise, size wise, and class number wise. The logical > conclusion is then obvious. > > > Regards, > Alan > > On Jul 11, 2008, at 9:15 AM, Jeremy Haile wrote: > >> I'm completely open to delaying the vote. However, I am curious as to >> your thoughts. Do you think there are more opinions out there? Or that we >> haven't fully discussed it? >> >> I started to feel like we were going in circles, repeating the same >> arguments over and over. And no one new was contributing opinions. That's >> why I suggested the vote. >> >> >> On Jul 11, 2008, at 12:12 PM, Alan D. Cabrera wrote: >> >>> With my champion/mentor hat on I would have to say that this vote is >>> premature. >>> >>> >>> Regards, >>> Alan >>> >>> On Jul 11, 2008, at 8:52 AM, Les Hazlewood wrote: >>> >>>> I'm calling for a vote to use a thin wrapper API (that already exists, >>>> just not integrated) as our components' primary interface for logging >>>> functionality. This would not be a logging framework, but just simply >>>> delegate to any implementation: Commons Logging, SLF4J, etc. >>>> >>>> +1 will be a vote in favor of incorporating this change. >>>> -1 will be a vote in favor of NOT incorporating this change. >>>> 0 will be the usual abstain vote. >>>> >>>> Thanks, >>>> >>>> Les >>>> >>> >> >> > >
