[armedbear-devel] Changes committed to org.sciencecommons.lisp.protege
alanruttenberg at gmail.com
Fri May 21 13:52:29 UTC 2010
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.
> > like to retain this capability. It uses bsh.ClassManager but it might do
> > 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
> > list of classes to index.
> That might be problematic. Do you iterate through the classpath
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*.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the armedbear-devel