This is an odd one, most probably due to the order in which the logging
jars are found in the classpath provided by Maven to the
jbehave-maven-plugin.
As a workaround, you can always run your JUnitStory using the
maven-surefire-plugin or maven-failsafe-plugin.
Just as a side note, could you not explicitly tell your logging
configuration which logger to lookup, without relying on the discovery
mechanism, which in turn relies on the order in the classpath?
On 08/10/2014 03:05, Dariusz Lorenc wrote:
Thanks for a quick reply. Really appreciate it.
I didn't know the jbehave is not using any logging framework. Now I'm
really puzzled. Wonder if any of the jbehave's dependencies could
cause that issue.
I did try with the logback dependencies at the plugin level, as you
suggested. Unfortunately it didn't help at all.
I'm attaching a sample project which reproduces the issue. Hope it
goes trough as an attachment. Just unzip it and run mvn integration-test.
You should see something like this, when it fails:
Then it should be a Logback instance (FAILED)
(org.junit.ComparisonFailure:
expected:<[ch.qos.logback.classic.]Logger> but
was:<[org.slf4j.impl.Simple]Logger>)
As you would see there is not much in that project. There is a unit
test (LogTest) which check for the right Logger class name. And that
seems to always pass.
The LogShouldNotMisbehaveSteps class obtains logger in one step and
asserts Logger's class name in another step. And that seems to fail
when run from maven, but passes when run as junit from the IDE.
Give it a go, and please let me know if you find anything interesting.
Cheers,
Dariusz
On Tue, Oct 7, 2014 at 6:14 PM, Mauro Talevi
<mauro.tal...@aquilonia.org <mailto:mauro.tal...@aquilonia.org>> wrote:
There's nothing dodgy about log-related in JBehave, simply because
there is no logging framework used.
What's usually quite dodgy is the logging frameworks' classloading
and dynamic lookups, which don't play well with Maven's rather
strict classloading.
To overcome classloading issues, it should suffice to declare your
logging framework's dependencies at plugin level, rather than
project level:
http://jbehave.org/reference/stable/maven-goals.html
If it doesn't work then please us send a sample project that
reproduces the issues.
Cheers
On 07/10/2014 03:44, Dariusz Lorenc wrote:
Hi,
I've been trying to get JBehave (3.9.4) to work in one of my
projects, but I'm experiencing some odd behaviour with the slf4j
binding. Hope somebody can help to pinpoint it, and confirm, or
deny, that JBehave, or its maven plugin is a culprit here.
I'm using dropwizard (0.7.1) in my project which in turn uses
logback, and comes with all the logback dependencies as well as
slf4j-api etc. Based on that, Dropwizard seems to assume that
org.slf4j.LoggerFactory.getLogger(...) would always return an
implementation of ch.qos.logback.classic.Logger (they cast the
result to that Logger type).
I have a very simple JBehave test, which tries to start up the
service (dropwizard). When I run it from eclipse, everything
works fine. However when I run it from maven, when dropwizard's
service is starting up, I'm getting an exception like this:
Caused by: java.lang.ClassCastException:
org.slf4j.impl.SimpleLogger cannot be cast to
ch.qos.logback.classic.Logger
at
io.dropwizard.logging.LoggingFactory.bootstrap(LoggingFactory.java:37)
at
io.dropwizard.logging.LoggingFactory.bootstrap(LoggingFactory.java:31)
at io.dropwizard.Application.<clinit>(Application.java:20)
That is caused by the dropwizard code trying to do that cast. For
some reason, in that scenario only, slf4j's getLogger returns
org.slf4j.impl.SimpleLogger. I checked my classpath/dependencies
to make sure I don't include the slf4j-simple jar anywhere. The
only slf4j bindings I have is the native logback implementation,
which comes with dropwizard. No slf4j-simple jar, no
org.slf4j.impl.SimpleLogger on my classpath. So how come it shows
up in the runtime when running from maven?
I even tried to strip the project down completely. I removed
dropwizard, and just left slf4-api, logback and jbehave. The
JBehave test was modified to just print out the class name of the
logger retrieved by the same getLogger method.
And same result again - SimpleLogger (slf4j-simple) when running
from maven, logback logger when running from the IDE.
To prove it's somehow JBehave related, I created a plain junit
test (no jbehave), which just prints out the logger's class name.
It always returns the right logback Logger, when run from eclipse
or maven.
So it seems to be only maven-JBehave combination which always
results with slf4j-simple binding. That makes me think that
JBehave (or actually its maven plugin) could be doing something
(dodgy?) log related under the hood. Could somebody confirm that?
And if so, does anybody know a good workaround? Apart from
Cucumber, of course :)
Any help is much appreciated.
Thanks,
Dariusz
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
