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 <[EMAIL PROTECTED]> wrote: > > On 10/31/07, Rajini Sivaram <[EMAIL PROTECTED]> 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 >
