In the other thread I mention that the specter of a SLF4J dependency
is moot when one realizes that it's just the tiny API jar.
Regards,
Alan
On Jul 11, 2008, at 9:55 AM, Les Hazlewood wrote:
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
