Sebastien, I did come across (2), but I assumed that (1) was deliberately using a script name rather than module/classnames etc. to keep the code consistent across all scripts.
The original Tuscany code loaded scripts using threadContextClassLoader.getResource(scriptName). The changes I made replaced this with contributionClassLoader.getResource(scriptName), and the classloaders of all contributions with any matching import/export namespace are searched for the resource. This is where I came across (2) since I wasn't sure if the namespace in import/export should refer to the directory name of the resource. I didn't want to introduce a new <import.script/> because that meant changing the externals. To implement (1), there should be an URLArtifactProcessor for each script type, associated with each script file extension (eg. .rb), so that the file is added to the list of deployable artifacts of the contribution. There should also be a ModelResolver for each script type which matches the module/classname etc. from your example using the list of deployable artifacts. I am not entirely sure where the implementation of (2) fits. The SCA spec says: Technologies that use naming schemes other than QNames must use a different import element from the same substitution group as the the SCA <import> element. The element used identifies the technology, and may use any value for the namespace that is appropriate for that technology. For example, < import.java> can be used can be used to import java definitions, in which case the namespace should be a fully qualified package name. From this I would expect <import.rb/> to specify how Ruby imports are specified. At the moment <import.java/> which is the only one supported apart from <import>, is implemented by contribution-java. Do we need a new contribution-script to support a list of new <import.xxx/> statements in the contributions? Thank you... Regards, Rajini On 11/6/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Rajini Sivaram wrote: > > Hello, > > > > Implementation scripts are currently resolved by the thread context > > classloader. > > > > The code in org.apache.tuscany.sca.extension.helper.utils. > > ResourceUtil.readResource(String scriptName) is: > > ... > > //FIXME The classloader should be passed in > > ClassLoader cl = Thread.currentThread().getContextClassLoader(); > > URL scriptSrcUrl = cl.getResource(scriptName); > > > > I think scripts should be read from contributions, with contribution > > import/export semantics, using a model resolver which uses the > contribution > > classloader. > > > > There is similar code in <implementation.query/> as well which reads the > > xquery script using the thread context classloader, which also looks > like it > > should use a contribution based model resolver. > > > > Thoughts? > > > > > > Thank you... > > > > Regards, > > > > Rajini > > > > > > Rajini, > > You're right, all of these should use a model resolver for finding > script files. > > I'd like to raise two related issues: > > 1) Should we reference script implementation artifacts by script file > path or by artifact logical name? > a) <implementation.script script="samples/calculator/calculator.rb"/> > or > b) <implementation.ruby module="calculator"/> for modules and > <implementation.ruby class="calculator.Calculator"> for classes > > We're currently doing (a). I think that (b) will be better: > - will better fit with the specifics of each scripting language > (supporting modules, classes, functions etc.) > - more in line with what is done for other languages in SCA (Java, BPEL, > etc.) > - will also allow you to use modules from a Ruby standard library for > example (on the Ruby runtime path). > > 2) How does the application developer reference script artifacts in > imported contributions when the only import mechanisms we have right now > are <import> for XML namespaces and <import.java> for Java package > names... huh looks like a hole in our import story :) > > Implementing model resolvers for the scripts is a good first step, my > guess is that it'll lead you to have to resolve (1) and (2) :) > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
