⚠	NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket. The ImageJ project now uses GitHub Issues for issue tracking. Please file all new issues there.

Ticket #1094 (closed defect: fixed)

Opened 2012-04-10T11:33:43-05:00

Last modified 2012-04-19T14:21:57-05:00

Classpath problem with third-party jar libraries

Reported by:	curtis	Owned by:	dscho
Priority:	major	Milestone:	~~imagej2-b2-bugfixes~~
Component:	Core	Version:	2.0.0-beta1
Severity:	critical	Keywords:
Cc:	aivar	Blocked By:
Blocking:

Description (last modified by curtis)

When a plugin depends on other libraries in the jars folder, the dependent classes cannot be loaded.

For example, add the LOCI update site ( https://sites.imagej.net/LOCI/), install the plugins, then run the Spectral Lifetime Analysis plugin. An error is emitted:

Plugin or class not found: "slim.SLIM_PlugIn"

This happens because a class in jars/curve-fitter-1.0-SNAPSHOT-with-libs.jar cannot be found, and then ImageJ1 decides to get creative.

But really, the root problem is the handling of the jars and plugins folders by the ImageJ2 class loader.

Change History

comment:1 Changed 2012-04-10T11:34:14-05:00 by curtis

Description modified

comment:2 Changed 2012-04-10T11:35:09-05:00 by curtis

Cc aivar added

comment:3 Changed 2012-04-10T12:51:12-05:00 by dscho

The solution should be pretty easy: force the class loader in IJ1 (IJ.classLoader IIRC) to point to the current one. It should probably happen in the legacy service. The tricky part is to forbid IJ1 from re-setting the classLoader field. Happily, this field is private for the moment (although I have little illusions about the volatility of such attributes in IJ1). Therefore it will be enough to Javassist the (package-local) setClassLoader() and the (public) getClassLoader() method of the ij.IJ class.

comment:4 Changed 2012-04-19T14:21:57-05:00 by dscho

Status changed from new to closed
Resolution set to fixed

Fixed in a0b21df5986e0d54e8460387d9eb78148f9532c0.