On Jul 14, 2008, at 7:00 AM, Les Hazlewood wrote:
Yet again, I'm NOT writing a proper abstraction layer to handle any
underlying implementation.
But everyone else says you are writing an abstraction layer. I
prefer to
call a rose a rose. Call it what you want and we shall agree to
disagree.
On Mon, Jul 14, 2008 at 9:04 AM, Jeremy Haile <[EMAIL PROTECTED]>
wrote:
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?
For the like 12th time, this is the problem I'm trying to solve:
I have answered all these issues in previous posts with compelling
arguments that have gone unanswered.
1. Proper low coupling/high cohesion with all aspects of our API,
logging included.
Not a problem but a goal and one that the SLF4J API provides
already. You
have not yet provided a compelling argument as to why the SLF4J
API does not
provide this. Could it be that it doesn't have
org.apache.jsecurity as a
starting package name? :)
2. Use SLF4J as the primary logging mechanism if it is in the
classpath.
Not really a problem to be solved. You are merely restating how
your
logging mechanism would work.
3. Graceful Degredation if SLF4J is not in the classpath. Note
that
my solution for checking if it is in the classpath will NOT
result in
the class loader issues that Commons Logging has. This is
possible
due to #1.
A tenuous use case at best and will only happen to the grad
student first
using the product. The *last* thing we want to happen is for a
user to
think that he has everything buttoned down when in fact he was
missing a
dependency and we were hiding that fact from him.
Let's keep in mind what we are building. This is not something
to help my
dad's office assistant make a web site to post pictures of his
kids. It's a
security framework. People arrive at this this task with girded
loins. The
LAST thing you want is automagical things going on behind the
scenes,
especially when it comes to security.
4. No _forced_ dependencies. This is possible due to #1.
We talked about this many times before and I had looked forward
to your
comments. I will repeat my points here.
Many projects create "uber" jars, which minimize dependencies, to
make
things easier for the grad students and other novices to use,
e.g. spring.
It has always been my experience that once their gasp of the
material
matures they always cast off the training wheels a exert a finer
degree of
explicit control.
The specter of a SLF4J API dependency is moot when one realizes
that it's
just the tiny API jar.
JSecurity Logging API == SLF4J Logging API
functionality wise, size wise, and class number wise. The
community will
require that and will not accept a dummied down API. With that
said, what's
the point in re-inventing a logging API that people who have
years of
experience in that field have already come up with?
Given the above points then the two are roughly equal
functionality wise,
size wise, and class number wise and the argument about coupling
3rd party
dependencies in this case is moot.
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)
There's nothing wrong with it if the code is so trivial that a
monkey
could understand it. I'm not asking anyone to do ANY effort.
I'm not
asking anyone to maintain it. I've even said that if we
actually have
a problem with it - that is, something _actually_ comes up _in
practice_ that indicates it is not working as expected, that
I'll do
the 5 minute code change it takes to force the SLF4J dependency.
Here you are dead wrong. The community is against ad hoc
inclusions of
code that is not needed, regardless if someone else is doing the
work.
You have nothing to lose. You have the above 4 points to gain.
That
no one here has to lift a finger and won't affect their coding
at all
and _still_ I'm getting pushback is driving me nuts. Just try
it for
Pete's sake. Then we can move on and no one here will ever have to
worry about this again.
Half of your points are not problems at all. The other half are,
at best,
conveniences not show stopper problems that need to be solved.
I would reverse this argument and ask you to try what clearly the
overwhelming majority of the community wishes and use the SFL4J
API. On
that happy day when the community is up in arms and are clamoring
for
another abstraction logging layer on top of an abstraction
logging layer on
top of a logging layer, you can always tell us "I told you so".
Regards,
Alan
