[Esapi-dev] Apache Commons Logger ESAPI Implementation

[chrisisbeef at gmail.com]

This is where the discussion of the componentization of ESAPI really needs to come into play. I agree with David that the number of dependencies required all around is pretty overwhelming and is playing into the inability for some developers to get ESAPI implemented in their applications. 

I suggest before we start adding more dependencies into the core project, that we discuss our plan for ESAPI components or plugins and get a core jar that has *no* external dependencies. 

I think this will be a very important step in getting general acceptance from potential adopters. I know that applications that the ones I maintain have large dependency collections already, and each time you add something new you have to consider it's dependencies and transitive dependencies as well as be aware of any dependency conflicts in that chain. The smaller initial footprint we can give ESAPI, the easier it will be for advocates to justify getting it into their respective applications.

This is my $0.02 on the subject. 

On Tue, Feb 9, 2010 at 8:37 AM, Ed Schaller <schallee at darkmist.net> wrote:
> 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.

>>>------>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktxgTwACgkQ8kiOCKEpeEF4QACfcnAuNDVV2470q/1JPlA1kqC/
otEAn3UpoUfB04dUsvqN9IyCCQATNfLL
=yMw3
-----END PGP SIGNATURE-----

_______________________________________________
Esapi-dev mailing list
Esapi-dev at lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-dev



-- 
Chris Schmidt

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

OWASP ESAPI for JavaScript
http://code.google.com/p/owasp-esapi-js/

Yet Another Developers Blog
http://yet-another-dev.blogspot.com

Bio and Resume
http://www.digital-ritual.net/resume.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-dev/attachments/20100209/7d4de5ff/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 271 bytes
Desc: OpenPGP digital signature
Url : https://lists.owasp.org/pipermail/esapi-dev/attachments/20100209/7d4de5ff/attachment.bin