ant elder wrote: > In JIRA TUSCANY-40 Jim commented that to test functionality it would better > to add unit tests in the core projects rather than as samples. I agree, I'd > added the JavaScript sample as that was the way the Java component did the > test, but now I've a bunch of other functional tests I'd like to add for > JavaScript so how should I add them? > > I'm guessing one reason its done like this with all the separate sample > projects is because its hard to do tests in a single project as that can > only have the one sca.module file in the classpath. I don't suppose > o.a.t.core.client.TuscanyRuntime could be changed to support passing in the > name of a module file? Looks like a simple change to make... >
Doing something like this would make life easier for the Tomcat integration as well. I ran into several issues there trying to separate startup of the runtime from the startup of each the module components associated with each web application. I would propose we separate the bootstrap process for the runtime from the mechanism used to locate the configuration information itself. In http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200602.mbox/[EMAIL PROTECTED] there are a couple of ...'ed bits where the configurations get loaded. These are currently hard-coded into TuscanyRuntime but could be converted to external strategies. I'd suggest two strategy interfaces: one for system bootstrap and one for loading applications (where an application is anything may be loaded/unloader after the system has been booted). interface SystemConfigurationLoader { // load the bootstrap configuration for a runtime AssemblyModelObject loadSystem(SystemAggregateContext); } interface UserConfigurationLoader { // load a user configuration from some source e.g. an XML file AssemblyModelObject load(RuntimeContext); } I'm proposing two because I think there will be different services available to each loader e.g. the system loader should probably assume nothing has been loaded except for a SystemComponentContextBuilder. We'd have different implementations of these for different ways in which configuration information could be loaded. One would just load from a set of XML files (which would give you what you were asking for), another would load based on the packaging model for a webapp (whatever that turns out to be). To keep things simple for the user, this would just extend the current API for TuscanyRuntime and the implementation could use suitable defaults. However, it would provide the hooks needed to support the more complex cases (like having to reload modules in a test suite, or having to reload modules as the set of deployed webapps changes). -- Jeremy
