Error dialog pop up in RC3 when closing the ImageJ window after workflow execution.
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
[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.
#2 Updated by Christopher Brooks almost 10 years ago
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.
#3 Updated by jianwu jianwu almost 10 years ago
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.
#7 Updated by jianwu jianwu almost 10 years ago
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.
#8 Updated by Derik Barseghian almost 10 years ago
This seems relevant:
#9 Updated by Derik Barseghian almost 10 years ago
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?
#11 Updated by Derik Barseghian almost 10 years ago
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.
#14 Updated by Christopher Brooks over 9 years ago
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.
#15 Updated by Sean Riddle over 9 years ago
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).