[Mifos-developer] slf4j-nop should be excluded, and slf4j-log4j12 be added

[Michael Vorburger]

Hello,

I've been toying with something, and came across a subtle problem in
the poms which I propose to address with the attached diff:

Basically I've tried something with an external library which uses
slf4j, and for a moment was stunned that I couldn't get any logs at
all of that thing. It turned out that this is because Mifos has an
slf4j-nop.jar on it's CP, pulled in transitively from dbunit; c.f.
http://www.slf4j.org/manual.html about slf4j-nop: "Binding for NOP,
silently discarding all logging." (The slf4j-nop probably does not end
up in the Mifos.WAR, because it's only scope runtime, but for m2e it's
just another JAR to put on Eclipse' CP; and my problem was in the
workspace in JUnits & a test main).

Simply excluding slf4j-nop leads to an 'SLF4J: Failed to load class
"org.slf4j.impl.StaticLoggerBinder". / SLF4J: See
http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.' at startup (of e.g. unit tests in workspace; haven't tried
deploying WAR in Tomcat). As Hibernate seems to also have a dependency
on slf4j(-api), and as Mifos seems to use Log4j code for Logging
(http://www.mifos.org/developers/wiki/LoggerConfiguration ?), I think
it probably makes sense to add that slf4j-log4j12 bridge then?

The attached proposed patch addresses this by an exclude for slf4j-nop
and adding a new dependency on slf4j-log4j12, with some fixes to
correctly use dependencyManagement at the top instead of repeating the
version (and exclusion) in every pom.xml, and I would like to suggest
it for integration.

I have NOT run the tests with this yet (slow!), may be one of you
could try? Should hopefully be fairly safe, I would think, at the
worst there could be some more (better!) logs from Hibernate printed
e.g. during Unit Tests (assuming that Hiberate logs only through
slf4j, and those got swallowed by slf4j-nop).

Regards,
Michael

_______________________
Michael Vorburger
http://www.vorburger.ch

[Udai Gupta]

Thanks Michael,

I have attached this patch on this http://mifosforge.jira.com/browse/MIFOS-2680

Udai

------------------------------------------------------------------------------

--
You received this message because you are subscribed to the Google Groups "Mifos Developer" group.
To post to this group, send email to mifosde...@googlegroups.com.
To unsubscribe from this group, send email to mifosdevelope...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mifosdeveloper?hl=en.

[Adam Monsen]

I tried it out on ^/branches/slf4jChange:

https://ci.mifos.org/hudson/job/branchs-slf4jChange/

[Michael Vorburger]

> I tried it out on ^/branches/slf4jChange: https://ci.mifos.org/hudson/job/branchs-slf4jChange/

Thank you! - I just had a look at that (only) failing
https://ci.mifos.org/hudson/job/branchs-slf4jChange/org.mifos$mifos-testFramework/1/testReport/junit/org.mifos.test.framework.util/SimpleDataSetTest/testGetDataSet/

Attached a .patch which solves that.

It would be cool if this could get into trunk - it's needed by what I
just posted (embedded Jetty thing).

[Udai Gupta]

Hi Michael,

It seems like the build(on hudson) gets slower after applying the
changes for slf4j. It's only making the acceptance tests slower, other
modules has no difference in execution time.

See before change
http://ci.mifos.org/hudson/job/head-master/1306/console and after
change time http://ci.mifos.org/hudson/job/head-master/1307/console

It's not noticeable on devs machine because the hudson run all
acceptance tests (around 176) "mvn clean install
-Pcontinuous-integration,tomcat6x,download-container" while "mvn clean
install" runs only 26 (smoke) acceptance test.

Would you (or someone) be able to see/find out why it's happening, and
how we can solve this?

Thanks,

[Michael Vorburger]

Hello Udai,

Thanks for getting back to this one! I'm not 100% sure why it's gotten
slower, but have a theory:

As I said initially, "Should hopefully be fairly safe, I would think,

at the worst there could be some more (better!) logs from Hibernate
printed e.g. during Unit Tests (assuming that Hiberate logs only

through slf4j, and those got swallowed by slf4j-nop)." ... could this
be what's going on here? I can't figure out where on the Hudson UI one
could see and compare the logs of 1306 and 1307?

Just a thought - but I have seen test suites getting slower with more
logs being written. - If this is it and those new log entries are of
no use, we could disable them?

Best,

Michael

_______________________
Michael Vorburger
http://www.vorburger.ch