[ 
http://jira.codehaus.org/browse/JBEHAVE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=264734#action_264734
 ] 

Paul Hammant commented on JBEHAVE-492:
--------------------------------------

In Pico-land you could register a component by a) instance to avoid the 
ThreadCaching stuff, b) have an even more primordial container that is plain 
'Caching' (equiv to Spring's Singleton scope), or c) register something by type 
in the otherwise ThreadCaching container, but with an explicit Cached behavior 
(for that there's about three ways), but here is one way:

steps1.as(CACHED).addComponent(new 
ClassName("housekeeping.EmptyCartIfNotAlready"));  

My problem right now is that I'm pinging back and forth from the case in work 
(that's busted on WebDriverProvider.get() in BasePage's ctor) and equivalent 
stuff in the Etsy tutorial which is not as sophisticated :-(

> ConfigurableEmbedder.addSteps(..) should take classes not instances.
> --------------------------------------------------------------------
>
>                 Key: JBEHAVE-492
>                 URL: http://jira.codehaus.org/browse/JBEHAVE-492
>             Project: JBehave
>          Issue Type: New Feature
>          Components: Core
>    Affects Versions: 3.x
>            Reporter: Paul Hammant
>             Fix For: 3.x
>
>
> public void addSteps(List<Class> steps) {
> }
> ... would be better.
> Why?  There's an instance that's made during the setup of a suite (refer 
> EtsyStories).  If you are running in multi-threaded mode, that **initial** 
> instance is **never** used during the running of scenarios.
> In multi-threaded mode, there's a constructor for BasePage that takes a 
> WebDriverProvider.  When it is passed in during the primordial instantiation 
> phase, no WebDriver has been initialized.  We don't want to do that of course 
> because (a) we know this **initial** instance is going to be garbage 
> collected and never used, and (b) on SauceLabs at least it would result in 
> browser opening in the cloud then closing (or maybe not closing, but never 
> used; I'm not sure).
> JBehave does not actually need the **initial** instance.  I believe this is 
> provable. Instead it could perfectly well use the class definition without 
> the instance ref somehow.   
> Proposal:  Long overdue, I think, but could for 4.x we shift to using 
> class-defs.  Either rework CandidateSteps to hold a Class rather than an 
> instance.  Or further do a away (move the logic elsewhere) with 
> CandidateSteps, and use the POJO Step's class-def directly. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to