Hi,
this is typically the kind of proposal we always go through. Some peeps
ask us to implement another layer on top of logger layers. They think it
will fix some kind of CL problem. We should resist as much as possible.
The reason it's really not a good idea is that those proposals are
driven by people who are using a specific logger and don't want to deal
with another one, or at least, don't understand how it should be done
the right way.
Slf4j so far is just a solution, not a simple one, not the best
documented, but it works. Let's stick with it, and help the people who
are using Clog or Log4j or any other log framework to understand how to
make JSecurity integrate with their projects. It should not be that
complex, we don't have a matrix of hundred of logger out there ...
A good example on how to give users directions :
http://mina.apache.org/logging-configuration.html
Hope it helps.
Les Hazlewood wrote:
Hi all,
I was contacted via private email yesterday about a company that wishes to
use JSecurity in their product, but they were concerned about our use of
Commons Logging, citing the now familiar classloader issues. It was
interesting timing because of my proposal to use SLF4J last week.
This gent's recommendation was that we have our own (very minimal) Log
interface that we would use in our classes instead of Commons Logging. He
brought up a number of cases of difficulty implementing frameworks in
companies that have their own proprietary logging framework (events,
monitoring, etc), and said it would be much easier and more flexible if they
could implement their own version of a Log interface to do what they need,
using their companies' APIs.
I think it is a good idea, and would be super easy - it is basically one
interface (Log) and maybe a 2nd (LogFactory, whatever). Then our default
implementation could use the JVM logger or SLF4J to allow any number of
pluggable logging implementations. This provides greater flexibility for
any environment. We already do the same thing for caching (Cache,
CacheManager) which in turn delegates to Caching product implementation
specific classes (ehcache, JCache, etc). Same concept.
The thing that sounds clean to me about this, is that if it was implemented,
we would have NO required dependencies on any 3rd party library. That just
feels sexy. But we can still have default implementations that use our
favorite infrastructure.
Any thoughts or objections?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
