Aladdin - Scala Bugtracking
[#1177] project: interpreter priority: low category: bug
submitter assigned to status date submitted
Nikolay Lex fixed 2007-06-17 18:51:25.0
subject [contrib #660] Does not set context class loader
code
===
println(classOf[org.apache.juli.ClassLoaderLogManager].getClassLoader())
println(this.getClass().getClassLoader())
println(Thread.currentThread().getContextClassLoader())
===

Must be executed as scala -classpath tomcat-juli.jar ./hello.scala

org.apache.juli.ClassLoaderLogManager is class availabe from jar specified in -classpath. You can use any class loaded from any jar instead of ClassLoaderLogManager.

This prints that context classloader is loader of scala itself, but not loader of -classpath classes.

However, context classloader is used by java.util.logging.LogManager (and many others) to load custom LogManager. But org.apache.juli.ClassLoaderLogManager is not available to loader of scala, so not available to LogManager.

As workaround I can execute

===
Thread.currentThread().setContextClassLoader(this.getClass().getClassLoader())
===

at the begin of execution. I think Scala should do this itself.
what happened
java.net.URLClassLoader@e1eea8
java.net.URLClassLoader@e1eea8
sun.misc.Launcher$AppClassLoader@a9c85c

what expected java.net.URLClassLoader@e1eea8 java.net.URLClassLoader@e1eea8 java.net.URLClassLoader@e1eea8
[back to overview]
Changes of this bug report
Nikolay  edited on  2007-06-17 18:56:18.0
Lex  edited on  2007-07-13 21:29:01.0

This seems reasonable. I have changed InterpreterLoop and ObjectRunner to set the context class loader. ScriptRunner, as shown in the bug report, also gets this behavior because it uses ObjectRunner.

I did NOT change Interpreter, though it is a close call. My thought is that the above three entry points are top-level ways to access Scala, while Interpreter has internal uses within programs. Thus, any code that uses Interpreter directly must set up the context class loader as they desire.