Yes, of course, but that doesn't change the fact that we've got a
mandatory dependency that _could_ be avoided for simpler deployments.
I just happen to value that more than most apparently :)
On Fri, Jul 11, 2008 at 12:52 PM, Alan D. Cabrera <[EMAIL PROTECTED]> wrote:
>
> On Jul 11, 2008, at 9:49 AM, Les Hazlewood wrote:
>
>> 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 :)
>>>
>>> Featherweight is a vague adjective. As I've mentioned before, I'm not
>>> sure
>>> that the community deserves a dummied down API. If one delivers the same
>>> functionality then one ends up with roughly the same API.
>>
>> That's very true. But I think that's the issue - JSecurity doesn't
>> use any of the more robust functionality that SLF4J might provide. We
>> always do this:
>>
>> if ( isBlahEnabled() ) {
>> log.blah(...);
>> }
>>
>> We never use anything else. So the wrapper API I came up with only
>> supports that. Now if we were going to use features like <a
>> href="http://www.slf4j.org/manual.html#mdc";>Mapped Diagnostic
>> Contexts</a>, then sure, a 1-to-1 overlap would be the case and of
>> lesser value.
>>
>> But yes, it is 'dummied down' as you say to only support what we need.
>> Again, its reducing coupling that is my favorite aspect, not so much
>> the overlap.
>>
>
> So, then it should be crazy easy for you to implement your
>
> SLF4J -> Acme Co Logging adapter
>
> no?
>
>
> Regards,
> Alan
>
>
