Allow the ProcessHandler's scope to be overridden in the XXX-processes.properties about chorus HOT 3 CLOSED

We need to review handler scopes, but I'm not sure the above example should be implemented as a Handler class - probably better as an ExcecutionListener which receives lifecycle events including start() and end() for the whole session. To do this we'd need to add a hook to specify a custom ExecutionListener, which we should really do anyway.

from chorus.

I see your point.
It would be nice if there was an example on how to write a custom ExecutionListener on the Wiki :-)

from chorus.

Have thought about this some more and we have decided to enhance scoping for Handler classes to support a feature scope (handler gets created once per feature, reused for scenario). We will also support initialization and destroy methods which are scoped by scenario/feature, so a feature-scoped handler can do some initialization and tear down for individual scenarios as well as feature start/end.

I think the ability to configure a process to be feature scoped would be a nice idea. To support this we can change the ProcessHandler to be feature scoped, and allow a process to be configured as 'feature' or 'scenario' - if scenario then a process will be shut down when the scenario ends, otherwise at the end of the feature.

We are also adding a special 'Feature-Start:" and "Feature-End:" section to the supported syntax - these are special scenarios which perform setup and tear down for a feature and would be a good place to start any feature-scoped processes.

For processes which need to start and stay running for a whole suite of tests, an ExecutionListener would still be the best place to do this, since we won't be supporting any kind of suite scoping, at least for now. We will add the ability to specify a custom ExecutionListener class in the next release.

More on the wiki soon

from chorus.