Re: Thread context classloader: Location of implementation scripts

[Jean-Sebastien Delfino <js...@apache.org>]

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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Thread context classloader: Location of implementation scripts

[Rajini Sivaram <ra...@googlemail.com>]

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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>