search

imagej / imagej-launcher

The ImageJ native launcher
https://imagej.net/learn/launcher
BSD 2-Clause "Simplified" License
21 stars 23 forks source link

Add a fallback to launch the ImageJ updater if net.imagej.Main could not launch #23

Closed dscho closed 9 years ago

dscho commented 9 years ago

Every once in a while (and more so in the beta phase) things do not quite work well together in the ImageJ startup. Even after the ImageJ components stabilize, with the flexibility of the SciJava service framework, it is possible for third-party components to interfere inadvertently with a successful SciJava context initialization.

In such cases, the user is stuck with a non-functioning setup at the moment.

Let's be nicer and use the fallback procedure established in Fiji (when the updater moved into ImageJ2) to help users get back to a working system: detect when the main method could not be called successfully and start the updater remotely, via bootstrap.js.

dscho commented 9 years ago

@ctrueden @hinerm I three more ideas about which I wanted to let you comment:

  1. The exception itself, the one that the main method triggered, could be useful information. So maybe it should be injected into the Javascript engine, as cause variable, and handled by bootstrap.js? (The JTextArea would then need to be wrapped into a JScrollPane, complicating the script further, but I think it would be a valuable change.)
  2. The user might not want to run the remote updater at all; should we give them a chance to say "no"?
  3. As long as the remote updater has not been loaded, the user will see that text window, but if that window is closed, the process will still go ahead. Should we EXIT_ON_CLOSE up until the classes are loaded successfully (and after that switch to DISPOSE_ON_CLOSE to prevent our own dispose() call from exiting the whole process; I might be wrong about that, though, haven't yet tested).
dscho commented 9 years ago

Answering myself:

The exception itself, the one that the main method triggered, could be useful information.

It is, and now it is even shown. Maybe the message should be improved, though.

The user might not want to run the remote updater at all; should we give them a chance to say "no"?

I tested this: closing the window triggers a shutdown of the JVM.

As long as the remote updater has not been loaded, the user will see that text window, but if that window is closed, the process will still go ahead.

In the test mentioned above, this was not the case. Closing the window quit the launcher.

So from my side, this is ready to merge.

dscho commented 9 years ago

Okay, now it is really ready to merge... @hinerm @ctrueden who wants a free commit? ;-)