On Fri, May 21, 2010 at 9:44 AM, Alessio Stalla <alessiostalla@gmail.com> wrote:
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