Antisamy 1.6 introduces log4j dependency about antisamy

[davewichers]

OK. I made it optional, and also added a few comments in the README on the new logging setup. I'd like @kwwall to review/test these changes w/ESAPI before I publish 1.6.1.

[kwwall]

@talios - The reason for this decision is that ESAPI, dating back to the earliest 2.x versions, delivered an AntiSamy policy file with an extraneous, never used '' node. And we assume that many ESAPI users have customized this and we do not wish to cause their policy files to fail, but still would like them to benefit from the XML schema checking.
However, not to long ago, when we phased out log4j 1.x as the default logger (because it had reached end-of-life), we made JUL the default ESAPI logger. (SLF4J was just new at the time and still having some of the bugs worked out.) So the problem is that if an application using ESAPI is using JUL rather than SLF4J, then when ESAPI invokes AntiSamy, AntiSamy ends up logging this:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

so they get no indication of what is going on at all if their old, possibly customized AntiSamy policy file schema validation fails, because if they are using JUL for ESAPI, they probably are not using SLF4J in their application either.

I was actually in favor of marking it optional, for the very reasons that you say, but Dave and I discussed it and decided together it would be best to make it required and allow the developers using AntiSamy to exclude it. Almost all the projects I deal with in my day job already exclude libraries in the Maven pom, so I don't think there's a big knowledge gap there.

[davewichers]

Thanks for reporting this issue so quickly. I have reimplemented the logging in the new 1.6.1 branch to only use slf4j. There are no imports or uses of log4j at all. I do import slf4j-simple so that AntiSamy logging will work if an app hasn't configured logging at all. But the importing app should be able to switch out the logger to whatever they want. Can you review/test this new 1.6.1 branch and let me know if you agree that these changes address your concerns?

[talios]

@davewichers I've just pulled the branch and building locally and everything seems to build fine on my project.

I think it may be better listing the slf4j-simple dependency with <optional>true</optional> :

https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html

Cheers

[davewichers]

@talios @kwwall - After testing AntiSamy with apps that don't have SLF4J enabled at all, we decided that we needed to include slf4j-simple (i.e., not make it optional). AntiSamy uses can still configure their slf4j setup to use a different logging library, but we need to include something that works, in case they don't have anything at all.

[talios]

Given that SLF4j uses class path scanning as its means of configuring bindings; generally you only include the binding you want your application to use. It's usually recommended for libraries to not depend on concrete bindings, merely the API package for this reason.

This will probably lead to forcing users who want logging to require adding <exclusion> elements against the dependency. An optional dependency should still work as expected, but should not cause Maven to fail to build if missing.

I'm not 100% on that, or the behaviour when you have multiple bindings on the classpath - I suspect that might end up using which ever it encounters first - which could be problematic; for me this isn't such as an issue as we configure global exclusions everywhere already.

I note the subsequent commits on the branch still leave src/main/resources/log4j2.xml included - which should probably be removed.

[talios]

Apologies if I came off as cold above - had a bad day at work :(

[kwwall]

@talios - Agree, both src/main/resources/log4j2.xml and src/test/resources/log4j2.xml should probably be removed. @davewichers - if you haven't pushed 1.6.1 to Maven Central yet, you may want to do this.

[talios]

@kwwall Cheers for the back-info - sounds all good then.

[davewichers]

This has been addressed in the 1.6.1 release that just went out. I removed the two log4j2.xml files as well.