[ https://issues.jboss.org/browse/JBIDE-19784?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-19784: ------------------------------------- This simply isn't going to work. The only workflow that our runtimelocator is called from is when the preference page for runtiems is up, and a progress-monitor dialog is on top of it. Opening a third dialog (our jbt runtime detection) will make the UI of the background pages (pref page, progress mon dialog) to appear frozen, EVEN if we're running the read-and-dispatch, since they're below us on the call stack. Furthermore, once our rt-detection finds some runtime definitions, and the user clicks "OK", it will create those runtimes nad servers. This will attempt to refresh the runtime preference page, which is actually 2 layers lower on the UI call stack, which simply freezes the UI entirely. Even if i could fix all that, I could maybe arrange a way to get a list of RuntimeDefinition objects that were found during scanning, but I wouldn't be able to get a list of wst.server runtimes that were found, since that's not part of the jbt runtime detection API. I had also considered simply firing a job to open the dialog, but the original wtp runtiem pref page will open an error message if no runtimes are found. So having an error message show up while we're showing up the jbt runtime detection page wouldn't work here either. -- This message was sent by Atlassian JIRA (v6.3.15#6346)