Bug #5026
closed
Error dialog pop up in RC3 when closing the ImageJ window after workflow execution.
Added by jianwu jianwu over 14 years ago.
Updated over 14 years ago.
Description
I found it when I executed the workflow: KeplerData\Kepler-2.0-Demos\demos\getting-started\03-ImageDisplay.xml on Windows 7 64 bit machine.
The execution runs correctly. But when I closed the ImageJ window, a window firstly show up asking 'Are you sure you want to quit ImageJ'. I clicked 'OK'. Then ImageJ quit with the attached error dialog: 'Unable to save preferences'.
The console message is as follows.
[null] * svgRenderingMethod = SVG_BATIK_RENDERING *
[null] ERROR (org.kepler.gui.MenuMapper:getActionFor:271) Exception trying
to create an Action for classname: <org.kepler.tagging.TagManagerAction>:
[null] null (java.lang.ClassNotFoundException: org.kepler.tagging.TagManage
rAction)
[null] 2010 ms. Memory: 208064K Free: 77278K (37%)
There is no such a problem when I tested it in Kepler trunk. But the console message also has the above ERROR message. So the error message in console is not related to ImageJ error dialog.
Files
I am unable to reproduce this error on my mac. Who can reproduce this?
I can reproduce this failure on a Windows 2003 machine where Kepler
was installed as admin and I'm logged in as a non-admin user. To reproduce
the failure, I click on the X in the upper right of the "ImageJ" window or
the X in the upper right of the "species-distribution.PNG" window.
The failure does not occur if I'm logged in as administrator (the user
who installed the Kepler-2.0-RC3 release.
The failure does not occur for me under Mac OS X 10.5.
I re-tested it. In my Windows 7 64 bit machine, the failure does not occur if I start Kepler using right-click menu item 'run as Administrator'. It only occur if I start Kepler using by double clicking Kepler icon in the desktop.
The Kepler RC3 is installed by Administrator.
I think I have figured out what was causing this. It appears to be an incorrect path in the workflow. I have updated the workflow, but will need to publish a new installer to confirm.
This should be fixed.
I will need a person with a Windows machine to re-download the RC3 installer (which has changed) and confirm before closing this bug though.
I still saw it in RC 5. Re-open it.
In my Windows 7 64 bit machine, the failure does not occur if
I start Kepler using right-click menu item 'run as Administrator'. It only
occur if I start Kepler using by double clicking Kepler icon in the desktop.
The Kepler RC5 is installed by Administrator.
I'm able to replicate this on XP. It looks like IJ_Prefs.txt gets written to the project dir (C:\Program Files\Kepler-2.0-RC5\) and so that can't happen as a non admin user. I wonder if we can configure imageJ to change where this file gets written?
I downloaded and tried w/ a newer ij,jar, 1.43u, but no luck, C:\Program Files\Kepler-2.0-RC5\ is still the path used for IJ_Prefs.txt.
So to sum up: Short of patching the ImageJ code, I'm not sure how to fix this. From my understanding the problem is just that ImageJ gives an error message when you try to close it (can't save IJ_Prefs.txt because it tries to write into the Kepler directory, which user doesn't have access to) and this is annoying. The ImageJ website says ImageJ needs to be installed in a place writable by the user. The workflow runs fine, and displays its result with ImageJ, and subsequent runs (and in subsequent sessions of kepler) of the workflow work as well. Can non-admin users live with the annoyance of this error dialog for now? I vote to bump this bug post 2.0.
Postponing to sometime post 2.0. This does not affect the correct execution of the workflows.
Bug 5066 was a duplicate of this bug.
In Bug 5066, David wrote:
(2) Fix for ImageJ so that preferences are stored in an area other than the
installation space. This may require a change to ImageJ source code.
The issue here is that the preferences are saved relative to the ImageJ jar
file, and the jar file is often stored in a real-only area. Solving problem (1)
will not solve this problem. A good solution if (1) is solved by downloading
added modules in a local area would be to perhaps isolate ImageJ to its own
module. Alternatively, the code of ImageJ could be changed to handle saving
preferences differently, but this would cause maintenance issues.
Fixed in r25200-1 in trunk. Now ImageJ configuration is stored in the persistent configuration for the common module. This is accomplished through a modified ij.jar file (which is committed, as well as a script to recreate it (in common/resources/scripts), and a module initializer added to core (Due to the module hierarchy, common cannot have a module initializer).
Hey Sean, could we submit your patch to the IJ folks? If we upgrade to a new version of IJ it sounds like we might have to write a new patch?
Original Bugzilla ID was 5026
Also available in: Atom
PDF
