I totally +1 what Alan said.
Can we move on and let this thread behind us, so that the project does
not stay 3 years in incubation, because of endless arguments ?
Alan D. Cabrera wrote:
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
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
