"regression" when loading jars (due class-loader isolation)

[kares]

I'd like to confirm that changes done in 9K are known (desired) :

consider a (pretty unusual) use-case where one sets up a JNDI context implementation :

TOMCAT_MAVEN_REPO = 'http://repo2.maven.org/maven2/org/apache/tomcat'
TOMCAT_VERSION = '7.0.61'

DOWNLOAD_DIR = File.expand_path('.')

def download
  catalina_jar = "tomcat-catalina.jar"
  catalina_uri = "#{TOMCAT_MAVEN_REPO}/tomcat-catalina/#{TOMCAT_VERSION}/tomcat-catalina-#{TOMCAT_VERSION}.jar"

  juli_jar = "tomcat-juli.jar"
  juli_uri = "#{TOMCAT_MAVEN_REPO}/tomcat-juli/#{TOMCAT_VERSION}/tomcat-juli-#{TOMCAT_VERSION}.jar"

  require 'open-uri'; require 'tmpdir'

  temp_dir = File.join(Dir.tmpdir, (Time.now.to_f * 1000).to_i.to_s)
  FileUtils.mkdir temp_dir

  downloads = Hash.new
  downloads[juli_jar] = juli_uri
  downloads[catalina_jar] = catalina_uri

  Dir.chdir(temp_dir) do
    FileUtils.mkdir DOWNLOAD_DIR unless File.exist?(DOWNLOAD_DIR)
    downloads.each do |jar, uri|
      puts "downloading #{uri}"
      file = open(uri)
      FileUtils.cp file.path, File.join(DOWNLOAD_DIR, jar)
    end
  end

  FileUtils.rm_r temp_dir
end

download

# (downloaded) FS based JNDI impl borrowed from tomcat :
load 'tomcat-juli.jar'
load 'tomcat-catalina.jar'

java.lang.System.set_property(
    javax.naming.Context::INITIAL_CONTEXT_FACTORY,
    'org.apache.naming.java.javaURLContextFactory'
)
java.lang.System.set_property(
    javax.naming.Context::URL_PKG_PREFIXES,
    'org.apache.naming'
)

puts javax.naming.InitialContext.new

... this is really just something used to bootstrap a JNDI testing environment ... certainly one would not do anything similar in production

ruby naming_script.rb works under 1.7.20 fine but does not under 9K (since pre2) :

downloading http://repo2.maven.org/maven2/org/apache/tomcat/tomcat-juli/7.0.61/tomcat-juli-7.0.61.jar
downloading http://repo2.maven.org/maven2/org/apache/tomcat/tomcat-catalina/7.0.61/tomcat-catalina-7.0.61.jar
javax/naming/spi/NamingManager.java:674:in `getInitialContext': javax.naming.NoInitialContextException: Cannot instantiate class: org.apache.naming.java.javaURLContextFactory [Root exception is java.lang.ClassNotFoundException: org.apache.naming.java.javaURLContextFactory]
    from javax/naming/InitialContext.java:307:in `getDefaultInitCtx'
    from javax/naming/InitialContext.java:242:in `init'
    from javax/naming/InitialContext.java:192:in `<init>'
    from java/lang/reflect/Constructor.java:526:in `newInstance'
    from naming_script.rb:50:in `<top>'
    from java/lang/invoke/MethodHandle.java:599:in `invokeWithArguments'
Caused by:
URLClassLoader.java:366:in `run': java.lang.ClassNotFoundException: org.apache.naming.java.javaURLContextFactory
    from URLClassLoader.java:355:in `run'
    from AccessController.java:-2:in `doPrivileged'
    from URLClassLoader.java:354:in `findClass'
    from ClassLoader.java:425:in `loadClass'
    from Launcher.java:308:in `loadClass'
    from ClassLoader.java:358:in `loadClass'
    from Class.java:-2:in `forName0'
    from Class.java:274:in `forName'
    from VersionHelper12.java:72:in `loadClass'
    from VersionHelper12.java:61:in `loadClass'
    from NamingManager.java:671:in `getInitialContext'
    from InitialContext.java:307:in `getDefaultInitCtx'
    from InitialContext.java:242:in `init'
    from InitialContext.java:192:in `<init>'
    from NativeConstructorAccessorImpl.java:-2:in `newInstance0'
    from NativeConstructorAccessorImpl.java:57:in `newInstance'
    from DelegatingConstructorAccessorImpl.java:45:in `newInstance'
    from Constructor.java:526:in `newInstance'
    from JavaConstructor.java:253:in `newInstanceDirect'
    from ConstructorInvoker.java:71:in `call'
    from ConstructorInvoker.java:157:in `call'
    from CachingCallSite.java:303:in `cacheAndCall'
    from CachingCallSite.java:141:in `callBlock'
    from CachingCallSite.java:145:in `call'
    from ConcreteJavaProxy.java:52:in `call'
    from CachingCallSite.java:303:in `cacheAndCall'
    from CachingCallSite.java:141:in `callBlock'
    from CachingCallSite.java:145:in `call'
    from RubyClass.java:842:in `newInstance'
    from RubyClass$INVOKER$i$newInstance.gen:-1:in `call'
    from JavaMethod.java:295:in `call'
    from ConcreteJavaProxy.java:148:in `call'
    from CachingCallSite.java:293:in `cacheAndCall'
    from CachingCallSite.java:131:in `call'
    from naming_script.rb:-1:in `invokeOther104:new'
    from naming_script.rb:50:in `RUBY$script'
    from MethodHandle.java:599:in `invokeWithArguments'
    from Compiler.java:111:in `load'
    from Ruby.java:833:in `runScript'
    from Ruby.java:822:in `runScript'
    from Ruby.java:752:in `runNormally'
    from Ruby.java:574:in `runFromMain'
    from Main.java:401:in `doRunFromMain'
    from Main.java:296:in `internalRun'
    from Main.java:225:in `run'
    from Main.java:197:in `main'

... likely related to the change in how JRuby's commad-line class-loader is setup // cc @mkristian

[mkristian]

yes, this due to not do

java.lang.Thread.current_thread.set_context_class_loader JRuby.runtime.jruby_class_loader

inside org.jruby.Main. this JNDI context needs to find its classes on the context classloader. the summary for OSGi and TCCL is very similar to this problem here: http://njbartlett.name/2012/10/23/dreaded-thread-context-classloader.html

the question is really if this is ONLY command-only code or if people do something like this for gem as well ?
IMO fail fast is the better approach !

[kares]

thought so, thanks for confirming!