...
[09:23:29 CDT(-0500)] <EricDalquist> I haven't ever seen a reality around that
[09:23:41 CDT(-0500)] <EricDalquist> granted I think we should just convert all of our portlets to slf4j/logback
[09:23:52 CDT(-0500)] <EricDalquist> and then we should be in a pretty stable situation going forward
[09:24:09 CDT(-0500)] <EricDalquist> I'll see if I can get one of our guys to start on that in our next sprint
[09:24:09 CDT(-0500)] <drewwills> i can create some tickets
[09:25:37 CDT(-0500)] <drewwills> is there one of those impl jars that's safe to include for all comers?
[09:26:06 CDT(-0500)] <EricDalquist> so the safest approach would be to:
[09:29:12 CDT(-0500)] <EricDalquist> - directly depend on slf4j-api, jcl-over-slf4j, jul-to-slf4j, log4j-over-slf4j
[09:29:56 CDT(-0500)] <EricDalquist> - add logback-classes
[09:30:10 CDT(-0500)] <EricDalquist> - switch to logback.xml for runtime logging config & logback-test.xml for unit test logging config
[09:31:09 CDT(-0500)] <EricDalquist> - setup the enforcer plugin to make sure we don't get "old" jars pulled in: https://github.com/Jasig/uPortal/blob/master/uportal-war/pom.xml#L664
[09:31:37 CDT(-0500)] <EricDalquist> it isn't terribly complex
[09:31:55 CDT(-0500)] <EricDalquist> the most annoying part of it is you end up having to <exclude> a bunch of common-logging transitive dependencies
[09:32:17 CDT(-0500)] <EricDalquist> but that results in any logging from any logging framework going through slf4j & logback