How about until we have a way to do extensions properly to fix the problem
Matthew is seeing the testcase could determine which is the application
default.scdl by seeing if the resource URL starts with the current working
directory which it can get from System.getProperty("user.dir")?...ant On 8/1/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote:
On Aug 1, 2006, at 11:28 AM, Matthew Sykes wrote: > FWIW, I think I've been running into a problem at build time > because of this exact issue. There's a bit of code in the > javascript sample HelloWorldTestCase.java test that gathers up all > of the META-INF/sca/default.scdl resources it can find. The test > then throws away the first resource in the enumeration assuming > it's the application's default.scdl and not the extension's > default.scdl. I think this is problematic - putting all the runtime code on the application classpath is asking for trouble. > ant elder wrote: >> I guess it somehow needs to find the URL to the default.scdl for the >> JavaScript extension, but thats just in a jar on the classpath and >> there's >> lots of default.scdl resources on the class path so how does it >> know which >> is the JavaScript one? >> And the once it has that URL it isn't real obvious (to me) how you >> could use >> that from the testcase to get the extension registered with the >> runtime. >> ...ant > > While the build generally succeeds, every once in a while the test > fails with an UnrecognizedElementException on implementation.js. I > added a System.out.println to the test to show which of the > resources was thrown away in the following code snippet and found > that the extension scdl can be discarded instead of the application > scdl. (I'm assuming this is because enumeration that comes back > from getResources doesn't have a specfied order.) > > At this point I guess I have to wonder if the name used for the > extensions' scdl should be something different from the default > application scdl name? It seems like it might be nice to do > something like gather up like all of the visible META-INF/sca/ > extension.scdl resources and add them to the runtime as > extensions. I don't believe this would be at odds with the current > extensions mechanism in the DirectoryScanExtender if it went after > extension.scdl instead of default.scdl. I don't think we want different types of composite for extensions and other things. We're trying to add extensions into test cases without defining an extension mechanism so it's not surprising things are not working properly. Perhaps we should back up a little and think about what we are trying to achieve. Putting a user hat on, here are the things that I would like to do: 1) Unit test a component without needing any SCA runtime infrastructure. I don't need Tuscany classes on the classpath to compile my component and I don't want to pollute my test environment with them. All I should need is my code and my test framework (for example, TestNG). 2) Function test a component in the SCA runtime. I have installed and configured Tuscany somewhere, adding in the extensions that I need. I want to test code as if it was running in that environment. Ideally I would like the runtime to boot quickly inside my test client but I would also like to be able to deploy the component to an already running environment. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
