[armedbear-devel] Changes committed to org.sciencecommons.lisp.protege

[Alessio Stalla]

On Fri, May 21, 2010 at 3:52 PM, Alan Ruttenberg
<alanruttenberg at gmail.com> wrote:
>
>
> On Fri, May 21, 2010 at 9:44 AM, Alessio Stalla <alessiostalla at gmail.com>
> wrote:
>>
>> On Fri, May 21, 2010 at 3:23 PM, Alan Ruttenberg
>> <alanruttenberg at 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