Binil Thomas wrote:
I am not sure why a ClassLoader needs to be injected into my scenario. I am not using it in my scenario, nor am I passing it on to the superclass constructor. Is it possible for the ScenarioClassLoader to first look for a constructor which takes a CL and if not fall back to the default constructor? This might help people who don't want to configure a ClasspathScenarioDefiner etc which might need a CL.
If you don't pass the ClassLoader to the ScenarioDefiner, it will use by default the Thread.currentThread().getContextClassLoader(), and you'll not be able to load your scenarios from the classpath (when using Maven).
Sure - you could say that you don't put your text scenarios in the classpath and you can define your own ScenarioDefiner, but the intention is to be explicit about the dependency injection of the ClassLoader that is being used - and yes, you can always ignore the injected ClassLoader if you so choose to do. But the general (and most common) use case requires it.
Putting logic in the ScenarioClassLoader would risk behaving in a "black-magic" kinda way (few people bother reading even the javadocs - that are not always available) and would violate the dependency injection paradigm. In the case at hand the object contract states that there is a dependency (the ClassLoader) and allows you to provide a default constructor with a default value (the current thread context ClassLoader).
Can I just ask what you why you find defining an extra constructor such a big imposition? IMO, it's a relatively lean contract to honour.
PS: The Maven plugin page does not yet have the configuration options.
They're in the static reference documentation - since they refer to the javadocs (also contained therein). You can download it from:
http://repository.codehaus.org/org/jbehave/jbehave-distribution/2.1/jbehave-distribution-2.1-bin.zip We should make these docs available online soon. I've also added a note in http://jbehave.org/documentation/configuring-scenarios/ Cheers --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
