On Fri, May 21, 2010 at 9:44 AM, Alessio Stalla alessiostalla@gmail.comwrote:
On Fri, May 21, 2010 at 3:23 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Do you have control on the classloader used by jss? If jclass works, it means that the classloader that loaded org.armedbear.lisp.Lisp knows about FileUtils. If you can force the jss classloader to use Lisp.class.getClassLoader() as its parent, it should work, too.
I do, but currently it depends on being able to dynamically load jars.
I'd
like to retain this capability. It uses bsh.ClassManager but it might do
to
work with bsh.classpath.BshClassLoader.
I didn't mean that you should lose that ability. If you have the chance to decide which parent classloader bsh.ClassManager gets to use, you can pass to it the classloader of ABCL's Lisp class. That will make ABCL's classes visible to it, while retaining the ability to load jars dynamically.
There's also my dwimming of classnames that depends on being able to get
a
list of classes to index.
That might be problematic. Do you iterate through the classpath somehow?
Yes. There are java accessors that tell me the classpath.
Since there's no general means to do that, people usually assume that everything in the classpath has been loaded from a physical jar residing somewhere on the filesystem or the net. OSGi might break that assumption.
How so? Looks like what they actually do is unpack all their jars to a temp directory. Haven't checked yet whether the java accessors will tell me the class path, but if not that information needs to be *somewhere*.
-Alan
Alessio