On Fri, Jul 11, 2008 at 2:54 AM, Emmanuel Lecharny <[EMAIL PROTECTED]
> wrote:
Les Hazlewood wrote:
Reason 1: What happens when the latest-n-greatest new logging
framework comes out in 2 years from now? Will we refactor again?
This is a possibility :) We don't live in a frozen world ...
True, but the concept of low coupling and high cohesion and
independence from 3rd party APIs is always a *good thing*. There's no
reason not to utilize it if it does not introduce noticeable
complexity and works in all current cases. My solution achieves both
of these.
I
suppose we could, but, why not just eliminate that possibility?
Well, it's not likely that our own logging system will also remain
unchanged for years.
The point is that _we_ would control the change when we feel it might
be necessary. This goes back to the low coupling argument.
Or
what if there is some flaw in SLF4J that makes it undesirable,
much as
happened to Commons Logging (I've seen the CL problems myself - they
are real, even if they are rare).
Then we switch to the 'next best framework'. So far, and it's now 2
years slf4j exists, it's pretty stable. And Slf4j has been designed
to
avoid the problems CL had.
I think you're slightly misunderstanding my proposal. SLF4J is still
my preferred logging framework. I don't want to write another one -
I'm only talking about a very thin wrapper, which in most cases, the
default implementation used will be SLF4J.
Our own lightweight wrapper API
makes JSecurity more resilient.
You will face users questions like : "why do I have to configure
the logger
in some way which is incompatible with the logger I already use?" ad
nauseam.
Nope, we won't experience this. I'm not writing another logger
subsystem. They use the one they already have, and there is no
configuration necessary, unless they want to use something _other_
than SLF4J or Commons Logging or the ones those two support. My
solution is absolutely 100% transparent to all existing users as well
as users of all the other logging frameworks.
Reason 3: I know you said something like "why would they even want
to
do that [implement their own logging framework]"? The sad reality
is
that there are many companies that have their own logging frameworks
that are used across the organization that are NOT built upon
standard
OS frameworks like SLF4J or Commons Logging - they are proprietary,
integrate with centralized monitoring servers, JMS, etc, etc. My
current client is one such company. The people who contacted me
yesterday are another company. Allan's current company is another
such company. They exist in greater numbers than I'd like to see,
but
they're out there.
Sure, but is this a reason because some companies (and as there are
millions
out there :) are
not using an existing framework to define a brand new logger system
which
will not be able
to cover all the cases anyway ?
Yes, that is the reason - but we don't have control over that. Most
of them are legacy frameworks, and won't be changed for years. And if
we're going to provide a ubiquitous security framework, we _should_ be
able to play nice in those environments too. _Especially_ if what I'm
talking about does not in any way affect current users or users of
Commons Logging or SLF4J. Its 100% transparent.
Reason 4: our own trivial wrapper API prevents us from a forced
runtime dependency on another library. This caters to:
a) deployment simplicity - just drop jsecurity.jar into the
classpath
and you're done. Add more jars if you want customized features.
b) lightweight environments. People can use JSecurity in any java
environment, from web apps to cell phones, without worrying about
requiring an extra 50k to few megs of dependencies. This better
enables JSecurity as being known as a truly ubiquitous security
framework.
c) controlled environments - that a security framework does not
require other frameworks is a piece of mind security-conscientious
users and software standards groups will appreciate
This is an interesting point which may deserve another thread.
At some point, if JSecurity is to be a standalone lib, that mean many
libs won't be used (commons-xxx, and such), and it may be a real
burden,
or at least a real cost. What libs are currently used in JSecurity ?
The current required libraries are commons-logging.jar, and if you use
our text-based configuration (as most people do), Commons Bean Utils.
But the only absolute requirement is commons-logging.jar. If my
proposition is incorporated, commons logging and SLF4J can still be
used, but they are not mandatory.
Reason 5: this is a feature desired by an actual end-user - not
something I'm just dreaming up or over-engineering. This means
there
is desire from an end-user that is representative of other companies
out there that might use JSecurity as well. If we do this now, we
don't have to worry about similar requests later (as Emmanuel
pointed
out happens from time to time) as JSecurity becomes more heavily
adopted outside of just web applications.
It depends. The problem is that if you have 100 companies using
JSecurity, 99 using Log4j and 1 using another system, you will hear
from the one company having problem with JSecurity, and not about
the
99 others. If you switch, this is very likely that you will start
having
some of the 99 companies complaining :)
Again, this will not happen. My solution is totally transparent, but
has the added benefit of supporting more use cases.
Cheers,
Les
