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 ...
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.
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.
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.
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 ?
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 ?
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 :)
And may be it's just because this one company has not been told
how to correctly integrate jsecurity within their application...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
