You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Rajini Sivaram <ra...@googlemail.com> on 2007/10/31 11:11:31 UTC
Thread context classloader: Location of implementation scripts
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
Re: Thread context classloader: Location of implementation scripts
Posted by 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
>
>
Re: Thread context classloader: Location of implementation scripts
Posted by 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
Posted by Rajini Sivaram <ra...@googlemail.com>.
Thank you, Ant.
No, I wasn't asking for help. I just want to make sure that my understanding
of which classloader was intended to be used is not different from the one
expected by others.
For script engines which have specific requirements on TCCL, you can either
add the jars to the CLASSPATH (eg. for rhino jar), or create a new TCCL
around the script invocation (eg. for application classes loaded from SCA
contributions).
I will submit a patch with the changes later today or tomorrow.
Thank you...
Regards,
Rajini
On 10/31/07, ant elder <an...@gmail.com> wrote:
>
> On 10/31/07, Rajini Sivaram <ra...@googlemail.com> 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?
>
>
> Go for it :) Or are you asking for help? One possible complication may be
> that some script engines require specific things in the thread context
> classloader, for example i think Rhino requires things like both the rhino
> jar and any application classes used by the script in the TCCL. Guess that
> could be handled by setting a custom TCCL around the script invocations
> though.
>
> ...ant
>
Re: Thread context classloader: Location of implementation scripts
Posted by ant elder <an...@gmail.com>.
On 10/31/07, Rajini Sivaram <ra...@googlemail.com> 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?
Go for it :) Or are you asking for help? One possible complication may be
that some script engines require specific things in the thread context
classloader, for example i think Rhino requires things like both the rhino
jar and any application classes used by the script in the TCCL. Guess that
could be handled by setting a custom TCCL around the script invocations
though.
...ant