[Esapi-dev] Apache Commons Logger ESAPI Implementation

Ed Schaller schallee at darkmist.net
Tue Feb 9 10:37:32 EST 2010

> imho, we do not need another dependency for an optional feature.   I vote -1
> for including this in the project and suggest it should be and extention.

A few thoughts on this subject. 

First, on Apache (Jakarta) commons logging (JCL), this would actually not
add another dependency as it is already a transitive dependency via
commons configuration (mvn dependency:tree). Commons logging is used
by a lot of projects including spring. Dismissing it out of had would
not be appropriate. The arguments against it primarily have to do with
it dynamically trying to deduce which logging system to ultimately log
to. This can cause issues depending on the class loader environment
it is running in and can be especially messy with osgi. The idea of
wrapping logging in a thin layer and letting the end application choose
the logging system it likes is a very sound idea.

Also, even if this added a new dependency, maven allows you to declare
certain dependencies as optional so they are not pulled in by default
(Jim, we should do this for log4j. JCL apps, like some of mine, will
actually find log4j in the class path and prefer it over java.util.logging
JUL even though it is not configured or used by esapi. I can block this
in my own pom.xml but as it isn't a strict dependency it would be better
to do it in esapi itself.)

A similar wrapper that I have considered suggesting or writing
myself (time being a factor) is slf4j. This is very similar to
JCL in principle. It provides a thin logging interface that can use
many different underlying logging system. It differs from JCL in that
instead of dynamically seeking a underlying logging system, it requires
a implementing jar to be present in the run environment. Effectively you
write your library using the slf4j api. The end application includes the
glue jar linking slf4j to the desired logging implementation. There is
even such a glue layer for slf4j to log to JCL and vice versa.

I have thought to suggest slf4j (or even JCL) before as doing a separate
logging integration for every logging system out there. If I had known
that others were actively doing such a integration I would have mentioned
it earlier (sorry). In general I would suggest moving toward slf4j or JCL
in the long term and away from specific logging integration with log4j or
JUL. This allows the end user to have the ultimate choice in the matter.

My +1 is for accepting a JCL integration at this point as it adds new
functionality and no new dependencies (thanks to whomever did it!). I
would like to also discuss moving all logging toward slf4j or JCL though I
would prefer slf4j as at some point esapi is going to need to run in osgi.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : https://lists.owasp.org/pipermail/esapi-dev/attachments/20100209/9b16a1ec/attachment.bin 

More information about the Esapi-dev mailing list