Isn't there also useStoryReporter()? Like so:
public Configuration getConfiguration() { return new MostUsefulConfiguration() .useStoryParser(new GherkinStoryParser()) .useStoryControls( new StoryControls() .doDryRun(TestConfiguration.getInstance().doDryRun()) .doSkipScenariosAfterFailure(false)) .useStepPatternParser(new RegexPrefixCapturingPatternParser()) .useStoryLoader(new LoadFromClasspath(this. getClass().getClassLoader())) .useStoryReporter( new StoryReporter() { // OP implements methods here.. }); } On Tue, May 13, 2014 at 7:23 AM, Frank Pedroza <fpedr...@part.net> wrote: > The key appears to have been related to the StoryReporter. > > > public Configuration getConfiguration() > { > return new MostUsefulConfiguration() > .useStoryParser(new GherkinStoryParser()) > .useStoryControls( > new StoryControls() > .doDryRun(TestConfiguration.getInstance().doDryRun()) > .doSkipScenariosAfterFailure(false)) > .useStepPatternParser(new RegexPrefixCapturingPatternParser()) > .useStoryLoader(new > LoadFromClasspath(this.getClass().getClassLoader())) > .useStoryReporterBuilder( > new StoryReporterBuilder() > .withFormats(Format.CONSOLE, Format.TXT, Format.STATS) > .withFailureTrace(true) > .withReporters(new LogginStoryReporter(LOG))); > } > > > class LogginStoryReporter > extends NullStoryReporter > { > private final Logger logger; > > public LogginStoryReporter(Logger logger) { > this.logger = logger; > } > > @Override > public void failed(String step, Throwable cause) { > logger.error("{} (FAILED)", step, cause); > } > > @Override > public void failedOutcomes(String step, OutcomesTable table) { > failed(step, table.failureCause()); > > StringBuilder message = new StringBuilder(); > > message.append("(Failed Outcomes) ").append(step); > for (Outcome<?> out : table.getFailedOutcomes()) { > message.append(out.getDescription()); > } > logger.error(message.toString()); > } > > } > > > On Mon, May 12, 2014 at 4:08 PM, Mauro Talevi > <mauro.tal...@aquilonia.org>wrote: > >> Can you be a bit more specific please. An example? >> >> On 12/05/2014 20:48, Frank Pedroza wrote: >> >> I'm attempting to capture where in a story is during a story run as well >> as any stacks that are showing up in the console, but not my log file. >> >> >> On Mon, May 12, 2014 at 12:41 PM, Mauro Talevi < >> mauro.tal...@aquilonia.org> wrote: >> >>> All components - including monitors - are configurable so you can swap >>> the default with your own: >>> >>> http://jbehave.org/reference/stable/configuration.html >>> >>> What use case are you trying to satisfy? Having say debug-level >>> logging being always written to a file in the background? >>> >>> On 12 May 2014, at 19:21, Frank Pedroza <fpedr...@part.net> wrote: >>> >>> Could you help me understand this a bit more or point me to something >>> that explains how I would configure the jbehave framework to support this? >>> >>> >>> On Fri, May 9, 2014 at 4:12 PM, Mauro Talevi < >>> mauro.tal...@aquilonia.org> wrote: >>> >>>> JBehave uses the monitor pattern that allows you to honour dependency >>>> injection properly. Most logging frameworks rely on static lookup >>>> mechanisms. >>>> >>>> If you want to use a logging framework you can still do so by providing >>>> a logging implementation of the relevant interfaces. >>>> >>>> Cheers >>>> >>>> > On 9 May 2014, at 22:09, Frank Pedroza <fpedr...@part.net> wrote: >>>> > >>>> > I'm new to the group so sorry if this isn't the right venue for this >>>> sort of question or if this has already been addressed, but why is any of >>>> the JBehave framework using System.out rather than something like slf4j? >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this list, please visit: >>>> >>>> http://xircles.codehaus.org/manage_email >>>> >>>> >>>> >>> >>> >>> -- >>> -------------------------------------------- >>> Frank M. Pedroza - Software Engineer >>> Partnet - Development >>> 801.708.5050 >>> >>> ----------------------------------------------------------------- >>> The nice part about being a pessimist is that you are constantly being >>> either proven right or pleasantly surprised. >>> -- George F. Will >>> >>> >> >> >> -- >> -------------------------------------------- >> Frank M. Pedroza - Software Engineer >> Partnet - Development >> 801.708.5050 >> >> ----------------------------------------------------------------- >> The nice part about being a pessimist is that you are constantly being >> either proven right or pleasantly surprised. >> -- George F. Will >> >> >> > > > -- > -------------------------------------------- > Frank M. Pedroza - Software Engineer > Partnet - Development > 801.708.5050 > > ----------------------------------------------------------------- > The nice part about being a pessimist is that you are constantly being > either proven right or pleasantly surprised. > -- George F. Will >