I don't think we should try it. I think we should drop it. I can't
figure out why we are still arguing about this. Like Alan just said -
what problem are we trying to solve?
There's no reason to add additional code and complexity if there
aren't problems to be solved. (that can't better be solved by just
using SLF4J - an established solution)
I don't understand the argument that we're just adding a few
delegating interfaces/classes - that's all that SLF4J is doing as
well. What is the argument against just using SLF4J? SLF4J has a
variety of API/implementation combinations to suit just about any
scenario. Worst case scenario we can even decide to embed the SLF4J
classes into one version of our JAR.
What scenarios are not being solved by the solutions that have already
been proposed that don't involve us writing our own logging
abstraction layer?
On Jul 13, 2008, at 10:31 PM, Tim Veil wrote:
I am responding to this email while laying in the fetal position and
gently sobbing :)
Ok, lets try it out! There I said it!
I'm going to be starting work on my next big project this week and
will be integrating JSecurity. I'll be glad to play around and see
how it feels.
Thanks,
Tim
On Jul 13, 2008, at 8:57 PM, Les Hazlewood wrote:
This is exactly what I've been trying for everyone on this list _NOT_
to think. I didn't write another logging framework. Its just a few
delegating interfaces/classes:
1. Is a logging abstraction framework present (SLF4J)? Ok, use it.
2. No logging abstraction framework present? Are we on JDK 1.4? If
so, use JDK 1.4 logging
3. None of the above applies? Ok, use System.out.
This is not a full fledged logging framework, and it is only a
minimal
abstraction at that.
I can't possibly understand why this concept of loose coupling/high
cohesion and Graceful Degredation is so hard for some people on this
list to appreciate!
This will NOT suffer from class loading problems. It still delegates
95% of effort to SLF4J.
I KNOW this is a good idea. In fact, I can guarantee you our
end-users will never have a problem with this. 99.9% of people will
never know about it, nor ever care. I'm so confident that this is a
non issue and will not cause us problems that I can say with absolute
comfort that the second someone says "this abstraction concept is
causing us problems", that I'd remove it in a heartbeat and just use
SLF4J natively everywhere.
If everyone is so comfortable with a quick search-and-replace
reverting the change (like I've already demonstrated with SLF4J),
there is no risk to us as a development team.
The fact that some on this list are shooting it down without even
_trying_ it, or seeing how it feels for a few weeks or months is
driving me insane. That's just closed mindedness when I've already
laid out a laundry list of why this is worth trying. We're an Open
Source INCUBATOR project - there is nothing wrong with just trying it
out.
If it doesn't work? Or it actually _does_ cause us a problem? I can
revert in 5 minutes. Why isn't that good enough piece of mind for
you
folks to actually say "ok, lets try it out?". If I end up being
wrong, and the 5 minute change has to happen, I'll gladly eat my
words
and revert. And, only THEN would be be _forcing_ SLF4J on our end
users - it doesn't have to happen now. What have you guys got to
worry about? I'm not even asking anyone to do a single thing.
On Sun, Jul 13, 2008 at 12:36 PM, Jeremy Haile <[EMAIL PROTECTED]>
wrote:
It's currently not being used, and if we reject the idea of a custom
logging framework (which it appears we have/will), the code will
be deleted.
