Andy and I worked late into the night last night debugging why the FanClassLoader wasn't working in Resin. It turned out to be a weird combination of security settings and a bug in Resin's compiling class loader. The point I took away was that we probably can't rely on a custom classloader to run Fan. It will create too many complications trying to get Fan installed on hosted sites.
So I tonight I made a few modifications to the Java runtime to run Fan completely off precompiled jars available via the application classpath. You can turn on this mode by setting the system property "fan.usePrecompiledOnly" to "true". In precompiled only mode the FanClassLoader is disabled and attempts to use it will throw an exception. Instead of emitting types from fcode, we try to load the class using the normal application classloader.
There were a couple places where I was using my classloader to do some special emit post-processing, such as setting the field which stores the Type instance. However with a small performance penalty I was able to move that code into the static initializations during the emit process (which is effectively the only hook available to me when the JVM is loading the classes for me).
I renamed the fake.rb command "jar" to "native" and added a new command called "jstub". The "native" command continues to work as before - it precompiles pods which include native code. The new "jstub" command precompiles pods without native code which normally aren't precompiled. The "full" commands continue to operate as before calling "native", but not "jstub". You can run both using "fake full jstub" if you want to precompile everything.
I also added a new Ruby script called "jonly" to run either fan or fant in precompile only mode. It will automatically setup the classpath to include all the jars it finds under lib/java as well as set the "fan.usePrecompiledOnly" system property. I was able to successfully run the entire test in precompiled only mode with the exception of compiler tests which are expected to fail.
Hopefully this approach should give us a simple deployment model into convoluted environments like Resin or Tomcat where classloaders can cause nightmare problems.
andySun 10 Sep 2006
I like this approach - it really simplifies deployment in servlet engines.
brian Fri 8 Sep 2006
Andy and I worked late into the night last night debugging why the FanClassLoader wasn't working in Resin. It turned out to be a weird combination of security settings and a bug in Resin's compiling class loader. The point I took away was that we probably can't rely on a custom classloader to run Fan. It will create too many complications trying to get Fan installed on hosted sites.
So I tonight I made a few modifications to the Java runtime to run Fan completely off precompiled jars available via the application classpath. You can turn on this mode by setting the system property "fan.usePrecompiledOnly" to "true". In precompiled only mode the FanClassLoader is disabled and attempts to use it will throw an exception. Instead of emitting types from fcode, we try to load the class using the normal application classloader.
There were a couple places where I was using my classloader to do some special emit post-processing, such as setting the field which stores the Type instance. However with a small performance penalty I was able to move that code into the static initializations during the emit process (which is effectively the only hook available to me when the JVM is loading the classes for me).
I renamed the fake.rb command "jar" to "native" and added a new command called "jstub". The "native" command continues to work as before - it precompiles pods which include native code. The new "jstub" command precompiles pods without native code which normally aren't precompiled. The "full" commands continue to operate as before calling "native", but not "jstub". You can run both using "fake full jstub" if you want to precompile everything.
I also added a new Ruby script called "jonly" to run either fan or fant in precompile only mode. It will automatically setup the classpath to include all the jars it finds under lib/java as well as set the "fan.usePrecompiledOnly" system property. I was able to successfully run the entire test in precompiled only mode with the exception of compiler tests which are expected to fail.
Hopefully this approach should give us a simple deployment model into convoluted environments like Resin or Tomcat where classloaders can cause nightmare problems.
andy Sun 10 Sep 2006
I like this approach - it really simplifies deployment in servlet engines.