Re: [jbehave-dev] Loggin in jbehave

[Frank Pedroza]

We addressed this need by introducing the LoggingStoryReporter as shown
early on in the thread.  This allowed us to continue capturing system outs
to the console (yuck) but also capture all our logging in a separate file.
We sent up 2 log4j appenders to do this.

On Thu, Jan 29, 2015 at 1:56 AM, Omer Shem-Tov  wrote:

> Hi,
> I'm trying to add logging to jbehave, and I'm not sure what is the best
> practice.
> beside this discussion
> http://www.mail-archive.com/dev%40jbehave.codehaus.org/msg08872.html I
> didn't find any documentation.
>
> I'm trying to add log4j properties from a file, so when I log messages
> using logger.debug(message) and above it will go to text file, and messages
> like
>  logger.info(message) and above will go to the console log.
>
> if I want also these messages to be shown in the html report?
>
>
> How can I do that?
> Why do I need to explicitly specify log4j as dependency in the pom?
>
> Thanks,
>   Omer
>
>


-- 
Frank M. Pedroza
---
Do not pray for easy lives. Pray to be stronger men. Do not pray for tasks
equal to your powers. Pray for powers equal to your tasks.
-- John F. Kennedy

Re: [jbehave-dev] mailing list confusion

[Frank Pedroza]

Thanks for the clarification.

One clarification I should provide is that my intention with using Ctrl+F
is to do a text search, not a format.  I'm using Ctrl+H for now.

On Tue, Nov 25, 2014 at 4:18 PM, Mauro Talevi 
wrote:

>  Hi,
>
> Firstly: those listed below are not mailing lists but web archives - gmane
> and mail-archive.As archives, they are neither active nor inactive and
> you don't need to be subscribed to search them.  You may use them to search
> for previous posts or you can post a question directly on the lists (as
> you're doing now ;-).
>
> Secondly:  CTRL-F is only supported to format tables, at the moment.   But
> you need to highlight the table for the action to be activated.To
> support the formatting of the entire story, an Eclipse formatter needs to
> be written.   If you have the time and the expertise, your contribution
> would be most welcome.
>
> Here's how:  http://jbehave.org/how-to-contribute.html
>
> Cheers
>
>
> On 25/11/2014 19:31, Frank Pedroza wrote:
>
> 2 issues:
>
> First:
> Sorry, but not sure how to answer this question.  This may be a noob
> question, but it seems like every site does it differently.
>
> This page (http://jbehave.org/mailing-lists.html) lists 5 mailing lists
> with no description of the intent behind them:
>
>- gmane.comp.java.jbehave.devel
><http://dir.gmane.org/gmane.comp.java.jbehave.devel>
>- gmane.comp.java.jbehave.user
><http://dir.gmane.org/gmane.comp.java.jbehave.user>
>- gmane.comp.java.jbehave.scm
><http://dir.gmane.org/gmane.comp.java.jbehave.scm>
>- dev@jbehave.codehaus.org
><http://www.mail-archive.com/dev@jbehave.codehaus.org/>
>- u...@jbehave.codehaus.org
><http://www.mail-archive.com/user@jbehave.codehaus.org/>
>
> Are these all active?  Should I be subscribed/following all of these?  Do
> I really need to go search all of these to see if a question I have has
> been addressed before?
>  Second:
>  There was a post on 9/17/2014 to u...@jbehave.codehaus.org titled "CTRL+F
> does not work in JBehave editor".  I haven't seen a response and I don't
> see anything listed in the jira (http://jira.codehaus.org/browse/JBEHAVE).
> Is this a known issue?  Should/will a jira be created for it?  What should
> the process be?  How can I as a community member help?
>
>
>

[jbehave-dev] mailing list confusion

[Frank Pedroza]

2 issues:

First:
Sorry, but not sure how to answer this question.  This may be a noob
question, but it seems like every site does it differently.

This page (http://jbehave.org/mailing-lists.html) lists 5 mailing lists
with no description of the intent behind them:

   - gmane.comp.java.jbehave.devel
   
   - gmane.comp.java.jbehave.user
   
   - gmane.comp.java.jbehave.scm
   
   - dev@jbehave.codehaus.org
   
   - u...@jbehave.codehaus.org
   

Are these all active?  Should I be subscribed/following all of these?  Do I
really need to go search all of these to see if a question I have has been
addressed before?
Second:
There was a post on 9/17/2014 to u...@jbehave.codehaus.org titled "CTRL+F
does not work in JBehave editor".  I haven't seen a response and I don't
see anything listed in the jira (http://jira.codehaus.org/browse/JBEHAVE).
Is this a known issue?  Should/will a jira be created for it?  What should
the process be?  How can I as a community member help?

[jbehave-dev] post test run callback

[Frank Pedroza]

Is there support in the jbehave framework for registering a post-test run
callback?  I was hoping for a addPostTestRunListener() type of method, but
don't see anything.  Currently, in our InjectableEmbedder impl, we're
calling some method that's part of an object we configured in our
Configuration impl.  It's obviously quite ugly as we have to cast to
accomplish this.  I do see EmbedderMonitor, but I'm having a difficult time
understanding the intent of many of the framework objects due to a lack of
javadoc.

Re: [jbehave-dev] Step Class Instance Reuse?

[Frank Pedroza]

I believe our observation has been that a new Step class instance is
created for each and every step method.  As such, we are using the context
pattern for passing state across Step classes as well as from one Step
method to another within the same Step class.

On Sun, Sep 7, 2014 at 2:33 PM, Mauro Talevi 
wrote:

> The simplest and most important of reasons is that JBehave and other BDD
> frameworks are not unit-testing frameworks.
>
> They are used for integration testing which by its nature is fundamentally
> different from unit testing.   For one thing, it spans multiple methods and
> classes, while each unit test corresponds to a single method.
>
>
> On 07/09/2014 22:28, Chad Wilson wrote:
>
>> I was quite confused by how jbehave and other bdd frameworks handle
>> instantiation.  Having familiarity with unit testing frameworks, I came in
>> with the expectation that steps classes would be handled like classes in
>> JUnit, one instance per method with instantiation handled by the framework.
>>
>> Is there a particular reason for deviating from this pattern other than
>> the complexity it would require for the framework to do instantiation?
>>
>> Chad
>>
>> On 9/7/2014 12:20 PM, Mauro Talevi wrote:
>>
>>> The steps classes are instantiated only once per run context, i.e. for
>>> the set of stories. The same steps classes are reused for all
>>> scenarios.
>>>
>>> A context object is the recommended way to hold state in a scenario,
>>> and you'd use a thread local if you are in multi-threading mode.
>>>
>>> If you need to reset the state before or after each scenario, you can do
>>> so via the @BeforeScenario and @AfterScenario annotations, or using the
>>> Lifecycle steps in your story.
>>>
>>> If you have a specific use case in mind, feel free to share it.
>>>
>>> On 07/09/2014 15:26, Anders wrote:
>>>
 Message Title

 No, no problem seen, and thanks for the quick reply.

 The reason I ask is just to know if the state of the steps class
 instance is guaranteed to be available during the whole scenario.

 We normally use a thread local singleton context manager to hold the
 state of the scenario (cleared before each scenario is executed) in
 order to have the scenario state available to all step implementations
 executing in the same thread.

 But sometimes it is just cleaner, I think, to store state locally in
 fields in the step implementation class, as long as all the steps that
 need the info are located in the same class.

 Also, then I assume that the step class instances may be pooled and
 reused after a scenario has finished?

 If so, we have to be careful to not let the state leak over to the
 next scenario that happens to use that same instance.

 Or are steps class instances always recreated for each scenario
 execution?

 I’ll have to dig into our JBehave configuration a bit more to learn
 how this can be set up in our case.

 *From:*Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
 *Sent:* den 7 september 2014 14:52
 *To:* dev@jbehave.codehaus.org 
 *Subject:* Re: [jbehave-dev] Step Class Instance Reuse?

 That depends how you configure your steps factory ...

 Sanity dictates that you ensure that the steps instances are unique
 (e.g. using the singleton mode of the dependency injection containers).

 Assuming this is true, then yes, the steps will always be executed
 from the same methods in the same class.

 Are you experiencing anything that may contradict this behaviour?

 On 07/09/2014 14:46, Anders wrote:

 Is it guaranteed that steps implemented in the same class will
 reuse the same step class instances when executed within the same
 scenario?

 Example:

 Scenario: My scenario

 Given step 1

 When step 2

 Then step 3

 And step 4

 Let’s say that step 1 and 2 are implemented in class A, and step 3
 and 4 are implemented in class B.

 When this scenario is run, is it guaranteed that step 1 and 2 will
 be executed in the same instance of class A, and step 3 and 4 will
 be executed in the same instance of class B?


>>>
>>
>> -
>> To unsubscribe from this list, please visit:
>>
>>http://xircles.codehaus.org/manage_email
>>
>>
>>
>
> -
> To unsubscribe from this list, please visit:
>
>http://xircles.codehaus.org/manage_email
>
>
>

Re: [jbehave-dev] jbehave plugin configuration

[Frank Pedroza]

Custom story language... for example, I want to define different Strings as
my comments


On Tue, Jul 8, 2014 at 7:42 AM, Mauro Talevi 
wrote:

> You've not answered my question.
>
> What do you mean by a custom language?
>
> On 8 Jul 2014, at 15:37, fernando guallini  wrote:
>
> I have the same issue, Is there a way to configure eclipse plugin with a
> customize language?
>
>
> 2014-07-08 3:57 GMT-03:00 Mauro Talevi :
>
>> Preferences > JBehave > Project Settings > Story Language drop-down list
>>
>> Or do you mean to support another language than the one in the list?
>>
>>
>> On 07/07/2014 21:05, Frank Pedroza wrote:
>>
>>> Is it possible to configure the JBehave eclipse plugin to use a
>>> different/customize 'Story Language'?
>>>
>>> http://jbehave.org/eclipse-integration.html
>>>
>>>
>>
>> -
>> 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

[jbehave-dev] jbehave plugin configuration

[Frank Pedroza]

Is it possible to configure the JBehave eclipse plugin to use a
different/customize 'Story Language'?

http://jbehave.org/eclipse-integration.html

Re: [jbehave-dev] tabular parameters whitespace

[Frank Pedroza]

bump on this issue as well... do others have this same need or am I unique
here?  Do others have another solution they're using to solve this?


On Fri, May 30, 2014 at 9:52 AM, Frank Pedroza  wrote:

> I'd like to be able to specify a bunch of values to send to a text field
> and submit for validation testing trying each value and was thinking that
> being able to specify whether or not a given column or cell is trimmed
> would be nice.  Ideally, I think having an optional delimiter within the
> cell would be best.  For example:
>
> | value | message |
> | foo | some message |
> | " foo " | some message |
> | "fo"o" | some message |
>
>
>
> On Fri, May 30, 2014 at 12:54 AM, Mauro Talevi  > wrote:
>
>>  That's correct, it applies to all values.   What's your usecase?
>>
>> On 29/05/2014 17:22, Frank Pedroza wrote:
>>
>> I see the tabular parameters documentation has a section on preserving
>> whitespace via the {trim=false}.  I assume there's nothing that allows
>> me to control that on a per column or per cell level, right?  Would there
>> be benefit to something like this?
>>
>> --
>> 
>> 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

Re: [jbehave-dev] MethodReturningConverter how-to

[Frank Pedroza]

I think what you're showing here is how to define a converter that is
scoped to a specific step class rather than any and all step classes or
would this converter get used whenever a Calendar was the expected
parameter type?  If the later, does this mean that I can only register a
single converter for a given type?  Alternatively, do all the registered
converters get iterated over and asked if they can handle a given type and,
if so, given the opportunity to do the conversion?


On Fri, May 30, 2014 at 12:53 AM, Mauro Talevi 
wrote:

> You don't use it directly.  Use @AsParameterConverter annotation:
>
> https://github.com/jbehave/jbehave-core/blob/master/
> examples/core/src/main/java/org/jbehave/examples/core/
> steps/CalendarSteps.java
>
>
> On 30/05/2014 01:27, Frank Pedroza wrote:
>
>> Can anyone explain how to use the MethodReturningConverter?
>>
>
>
> -
> 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

Re: [jbehave-dev] tabular parameters whitespace

[Frank Pedroza]

I'd like to be able to specify a bunch of values to send to a text field
and submit for validation testing trying each value and was thinking that
being able to specify whether or not a given column or cell is trimmed
would be nice.  Ideally, I think having an optional delimiter within the
cell would be best.  For example:

| value | message |
| foo | some message |
| " foo " | some message |
| "fo"o" | some message |



On Fri, May 30, 2014 at 12:54 AM, Mauro Talevi 
wrote:

>  That's correct, it applies to all values.   What's your usecase?
>
> On 29/05/2014 17:22, Frank Pedroza wrote:
>
> I see the tabular parameters documentation has a section on preserving
> whitespace via the {trim=false}.  I assume there's nothing that allows me
> to control that on a per column or per cell level, right?  Would there be
> benefit to something like this?
>
> --
> 
> 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

[jbehave-dev] MethodReturningConverter how-to

[Frank Pedroza]

Can anyone explain how to use the MethodReturningConverter?

[jbehave-dev] tabular parameters whitespace

[Frank Pedroza]

I see the tabular parameters documentation has a section on preserving
whitespace via the {trim=false}.  I assume there's nothing that allows me
to control that on a per column or per cell level, right?  Would there be
benefit to something like this?

-- 

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

Re: [jbehave-dev] BooleanConverter confusion

[Frank Pedroza]

Greek how?  I wrote the sample code to better understand the
BooleanConverter and I'm quite confused by the results.  Is the code not
obvious and the results different than people would expect?



On Sat, May 17, 2014 at 8:29 AM, Mauro Talevi wrote:

> This is Greek to me :-)
>
> See previous email ...
>
> > On 16 May 2014, at 22:55, Frank Pedroza  wrote:
> >
> > public static void main(String[] args) {
> > System.out.println("accepts :" + new
> ParameterConverters.BooleanConverter().accept(Boolean.TYPE));
> > System.out.println("true==true :" + ((Boolean)new
> ParameterConverters.BooleanConverter().convertValue("true", Boolean.TYPE)
> == true));
> > System.out.println("false==false : " + ((Boolean)new
> ParameterConverters.BooleanConverter().convertValue("false", Boolean.TYPE)
> == false));
> > System.out.println("unknown==null : " + new
> ParameterConverters.BooleanConverter().convertValue("unknown",
> Boolean.TYPE) == null);
> >   }
> >
> > produces:
> >
> > accepts :false
> > true==true :true
> > false==false : true
> > Exception in thread "main" java.lang.IllegalArgumentException: The
> String did not match either specified value
> > at
> org.apache.commons.lang.BooleanUtils.toBoolean(BooleanUtils.java:763)
> > at
> org.jbehave.core.steps.ParameterConverters$BooleanConverter.convertValue(ParameterConverters.java:498)
> > at
> com.partnet.emall.automation.ConfigurationProducer.main(ConfigurationProducer.java:86)
> >
> > WTF?
>
> -
> 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

[jbehave-dev] BooleanConverter confusion

[Frank Pedroza]

public static void main(String[] args) {
System.out.println("accepts :" + new
ParameterConverters.BooleanConverter().accept(Boolean.TYPE));
System.out.println("true==true :" + ((Boolean)new
ParameterConverters.BooleanConverter().convertValue("true", Boolean.TYPE)
== true));
System.out.println("false==false : " + ((Boolean)new
ParameterConverters.BooleanConverter().convertValue("false", Boolean.TYPE)
== false));
System.out.println("unknown==null : " + new
ParameterConverters.BooleanConverter().convertValue("unknown",
Boolean.TYPE) == null);
  }

produces:

accepts :false
true==true :true
false==false : true
Exception in thread "main" java.lang.IllegalArgumentException: The String
did not match either specified value
at org.apache.commons.lang.BooleanUtils.toBoolean(BooleanUtils.java:763)
at
org.jbehave.core.steps.ParameterConverters$BooleanConverter.convertValue(ParameterConverters.java:498)
at
com.partnet.emall.automation.ConfigurationProducer.main(ConfigurationProducer.java:86)

WTF?

[jbehave-dev] Multiple ParameterConverters of same type

[Frank Pedroza]

Is it possible to have multiple ParameterConverters of the same type?  I
ask because I have the following and it doesn't seem to be working.

public Configuration getConfiguration()
  {
Configuration config = 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,
WebDriverHtmlOutputWithImg.WEB_DRIVER_HTML_WITH_IMG)
.withFailureTrace(true)
.withReporters(new LoggingStoryReporter()));

config.parameterConverters().addConverters(
new DateConverter(new SimpleDateFormat("-MM-dd")),
new ParameterConverters.BooleanConverter("will", "will not")  //
add another boolean converter
);

return config;
  }

Re: [jbehave-dev] Why System.out rather than logging framework

[Frank Pedroza]

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 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  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 > > 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  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

Re: [jbehave-dev] Why System.out rather than logging framework

[Frank Pedroza]

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
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  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 
> 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  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

Re: [jbehave-dev] Why System.out rather than logging framework

[Frank Pedroza]

Is the PrintStreamStepMonitor on the right path?
http://jbehave.org/reference/stable/javadoc/core/org/jbehave/core/steps/PrintStreamStepMonitor.html


On Mon, May 12, 2014 at 12:21 PM, Frank Pedroza  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 
> 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  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

Re: [jbehave-dev] Why System.out rather than logging framework

[Frank Pedroza]

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 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  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

[jbehave-dev] Why System.out rather than logging framework

[Frank Pedroza]

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?