On Fri, May 21, 2010 at 3:52 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
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*.
Well, I don't know OSGi/Equinox, so maybe it's not a problem. In general, it might be. For example, JBoss 5 uses the concept of a VFS (virtual filesystem) to handle the separate classpaths of the applications. While you can ask for a classpath resource by name (that's built-in in Java), if you want to navigate through the resources you need to use JBoss-specific APIs. You cannot get a listing of all the resources using standard APIs, and since you don't get a reference to a jar:something but to a vfs://something, you cannot extract the jars, either.
Alessio