It's your right to use alternative implementations, but at least the
interfaces should be the same and the maven dependencies declared.
If you find there's a bug in an implementation, the best way to address
it is to provide a same project that reproduces it and perhaps a patch
for it.
On 30/07/2014 18:21, Emanuel Campolo wrote:
Please dont get me wrong. I do want to help. I've copied some classes
because i found out that I could have memory leak issues using the
FluentWebDriverPage.
I will send you some logs using a newly created project with the
jbehave-web archetype.
On Jul 30, 2014 1:09 PM, "Mauro Talevi" <mauro.tal...@aquilonia.org
<mailto:mauro.tal...@aquilonia.org>> wrote:
It seems to me that you're not even using jbehave-web. You've
copied selected classes from it into your project and using them
in a way which is different from jbehave-web, e.g. introducing
another factory abstraction.
If you'd help on using jbehave-web, including resolving issues
with its current implementation, we'd be happy to help.
If you're writing your own framework, then we can't help.
Cheers
On 30/07/2014 17:52, Emanuel Campolo wrote:
Hi Mauro, thanks for taking your time to reply.
I mentioned PerStoryWebDriverSteps as an example of how the
framework cleans up the resources. In this case, when the end()
method is invoked, the ThreadLocal<WebDriver> instance associated
with the current thread is removed but, if you'd used a
FluentWebDriverPage instead of a WebDriverPage, a
ThreadLocal<FluentWebDriver> will not be eliminated from the list
of thread locals.
Even though im not using the jbehave-core for running my tests,
Im coding a lightweight selenium-based framework using testng and
the jbehave-web project.
As you can see below, I had to re write some of the classes to
solve this issue where resources are not being removed by
the DelegatingWebDriverProvider (javadoc and reference to
jbehave-web will be added):
https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/DefaultWebDriverProvider.java
https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/pages/FluentWebDriverPage.java
This is where I invoke the end() method
https://github.com/emacampolo/hatchery/blob/master/src/main/java/com/hatchery/core/Suite.java
2014-07-30 12:06 GMT-03:00 Mauro Talevi
<mauro.tal...@aquilonia.org <mailto:mauro.tal...@aquilonia.org>>:
Hi,
the FluentWebDriverPage is simply a fluent-based facade using
a FluentWebDriver. The underlying WebDriverProvider is the
same as a non-fluent page and is injected in the constructor.
The PerStoryWebDriverSteps should use exactly the same
underlying WebDriverProvider (autowired via some
dependency-injection mechanism), so if the provider end()
method is invoked you shouldn't need to do anything else.
Are you experiencing or noticing a particular problem? If
so, could you share a project that reproduced it?
Cheers
On 29/07/2014 19:14, Emanuel Campolo wrote:
Hi all !
I've added the jbehave-web module to a personal project
where I use testng. I'm using the
FirefoxWebDriverProvider to manage the webdriver
instances, taking advantage of the ThreadLocal for
multithreaded tests.
My question is, even though I call the end() method every
time a test completes to remove the driver assigned to
the current thread, i don't know how to the same thing to
the FluentWebDriver (a thread local variable that the
FluentWebDriverPage has).
I noticed that , for example, the PerStoryWebDriverSteps
only executes driverProvider.end() but as in mentioned
above, i didn't find any clean up for the
FluentWebDriver instances that FluentWebDriverPage creates.
Thanks in advance :)
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
