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]
