Hi Jeremy,
Why not name them as extension.scdl. Though for most parts they might be
treated as any other scdl some where we treat them a little differently as
in adding them to extensions and so on. Infact a solution developer could
develop some extensions and applications and keep them all bundled
together. When deployed the SCA runtime is able to understand which ones
are application scdls and which ones are extensions scdls and treats them
accordingly. That way the SCA installation directories can be left alone
i.e. the user need not drop the extension jars in a predefined dir. and so
on.
Also am curious about the name 'default.scdl'. Why 'default'? Is it to
imply that these scdls will be automatically picked up and deployed? So can
I give other names to my scdls and if so is there a programming model to
explicitly mention about them or load them?
Thanks
- Venkat
On 8/2/06, ant elder <[EMAIL PROTECTED]> wrote:
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]
>
>
