+1
On Jul 14, 2008, at 12:50 PM, Emmanuel Lecharny wrote:
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
