uPortal IRC Logs-2013-03-22

Owned by Apereo Infrastructure
Last updated: Mar 22, 2013

[09:16:07 CDT(-0500)] <drewwills> morning folks... has anyone dug into the occurance of these? SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".

[09:16:38 CDT(-0500)] <EricDalquist> means that there isn't a slf4j binding avaialble

[09:16:44 CDT(-0500)] <drewwills> it looks as though perhaps non-slf4j webapps are the ones complaining, which is surprising

[09:16:45 CDT(-0500)] <EricDalquist> where are you seeing that?

[09:17:08 CDT(-0500)] <drewwills> catalina.out

[09:17:16 CDT(-0500)] <EricDalquist> ok

[09:17:19 CDT(-0500)] <EricDalquist> for which webapp?

[09:17:25 CDT(-0500)] <EricDalquist> so something is using the slf4j api

[09:17:31 CDT(-0500)] <drewwills> after CalendarPortlet and NewsReaderPortlet, for example

[09:17:37 CDT(-0500)] <EricDalquist> but don't have something that implements that api availabler

[09:18:13 CDT(-0500)] <EricDalquist> yeah like looking at CalendarPortlet

[09:18:22 CDT(-0500)] <EricDalquist> I see slf4j-api in lib

[09:19:33 CDT(-0500)] <EricDalquist> see: http://slf4j.org/codes.html#StaticLoggerBinder

[09:19:46 CDT(-0500)] <EricDalquist> one of "slf4j-nop.jar, slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.ja"

[09:19:49 CDT(-0500)] <EricDalquist> need to be on the classpath

[09:19:57 CDT(-0500)] <EricDalquist> those are all jars that implement the slf4j api

[09:20:30 CDT(-0500)] <drewwills> the slf4j-api jar is a transitive (in Calendar) of org.jasig.resourceserver:resource-server-utils

[09:20:53 CDT(-0500)] <drewwills> shouldn't one of those impl jars be a transitive of slf4j-api?

[09:21:11 CDT(-0500)] <EricDalquist> nope

[09:21:20 CDT(-0500)] <drewwills> the calendar doesn't seem to know or care that slf4j is in use

[09:21:23 CDT(-0500)] <EricDalquist> if it was then we get the error we saw in 4.0.10

[09:21:31 CDT(-0500)] <drewwills> ack

[09:21:36 CDT(-0500)] <EricDalquist> where you end up with conflicting logging impls

[09:22:41 CDT(-0500)] <drewwills> would be nice if project A could use project B w/o having to analyze and chase down it's dependencies

[09:23:12 CDT(-0500)] <EricDalquist> heh, that is a nice dream (smile)

[09:23:23 CDT(-0500)] <drewwills> i think we're seeing 6-8 of these at least at OHIO

[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