[#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] |
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. |