Community
Participate
Working Groups
Build Identifier: 3.6.0 I20100608-0911 I have some problems with the P2 prestart update. I'm following the 'prestartupdate' example. It seems like P2Util.checkForUpdates is not UI safe. It forces me to open the progress monitor only in an UI thread. The other thing is that, if I open the progress monitor in sync thread it throws me 'invalid thread access' exception. I could only run it inside an async thread. I have to check for the updates before the workbench is opened. But since its invoked asynchronously, it checks for the update only after the workbench is opened. - cCn you make update operation UI thread safe? - Why would it not run in sync UI thread? Please suggest me a solution that can check for the updates prestartup. Reproducible: Always
I know this was a problem (see bug 282333), but it looks like it was fixed for Helios. Can you look at the other bug report and see if that helps, if not, maybe something got missed during the tagging of the examples.
we "fixed" it in bug 282333 by moving the update check after the UI thread started up. If you instead want to check for updates before the UI is up, then you'll want to use a different progress monitor (NullProgressMonitor, etc.).
It works fine with NullProgressMonitor. I'm glad that I dont have to run inside UI thread, but the NullProgressMonitor doesn't show any progress information. It displays only 'Operation in Progress'. It updates and restarts properly on prestartup. I will be more happy to see progress information in my progress monitor. Please let me know if you have any suggestions. Thank you for suggesting the workaround.
(In reply to comment #3) > I will be more happy to see progress information in my progress monitor. Please > let me know if you have any suggestions. The issue we had in bug 282333 is that the workbench hook during prestartup happens before the event loop is started. So now, the example does the check in the workbench window postWindowOpen, so that the event loop is running. Progress shows using the ModalContext AccumulatingProgressMonitor (which uses async to dispatch progress to the UI). Are you saying that this is too late in your scenario? When is it that you would like the update check to happen? I'm marking this bug for M2 because I'm looking at other RCP issues then. But I'd like to understand better what your requirements are (and why doing it after the window opens is not sufficient)
I have a requirement to update the application before logging into the application. The Login dialog is displayed during preStartup(). - User opens the application - Check for updates, install (if any) and restart (if updates installed). (We have to show them the progress information) - Display Login dialog - Open workbench on successful login If I use Async thread, the update operation is invoked only after Logging into the application and the workbench is opened. So if there are any updates, the workbench is restarted and the user ends up in logging into the application twice. Also we don't want to restart the application just after logging in. Using NullProgressMonitor solves my problem, but my only concern is the progress information.
Note: The updates are downloaded and installed automatically. User can't intervene the update operation.
these bugs will be my holiday projects...
We have two different requirements to support. (1) check for updates as early as possible, but still able to show progress in the UI. I think we achieved this in bug 282333. (2) check for updates before any application UI at all is shown. This was the original intent of the prestartUpdate example (hence the name prestartup). Perhaps we need to hook into the splash handling stuff and show progress there?
(In reply to comment #8) > We have two different requirements to support. > (1) check for updates as early as possible, but still able to show progress in > the UI. I think we achieved this in bug 282333. > > (2) check for updates before any application UI at all is shown. This was the > original intent of the prestartUpdate example (hence the name prestartup). > Perhaps we need to hook into the splash handling stuff and show progress there? #2 - Yes, I'm right now passing a NullProgressMonitor; but I would like to use a regular progress monitor in the future (pre-startup).
There is an extension point defined for SplashHandlers and I believe you are far enough along in the startup sequence that you will be able to use them. The extension points look like: <extension point="org.eclipse.ui.splashHandlers"> <splashHandler class="earlyupdatetest.splashHandlers.InteractiveSplashHandler" id="earlyupdatetest.splashHandlers.interactive"> </splashHandler> <splashHandlerProductBinding productId="EarlyUpdateTest.product" splashId="earlyupdatetest.splashHandlers.interactive"> </splashHandlerProductBinding> </extension> You could override org.eclipse.ui.splash.BasicSplashHandler ... or if you want the Eclipse build IDs , splash screen position APIs etc. you could override org.eclipse.ui.internal.splash.EclipseSplashHandler (although I'm not sure how kosher it is to subclass internal classes). You should be able to use the progress monitor returned by BasicSplashHandler.getBundleProgressMonitor() to get a progress monitor you can interact with. Since the instance of your splash handler will not be public when you are running in WorkbenchAdvisor you need a way for your splash handler to register itself during it's init(). I would think a singleton would be sufficient here. I also suspect your implementation would not have to do much in the init() or dispose() other than call the super implementations and store itself in the singleton field. You can use the wizards to generate examples of splash handlers. Create a new RCP application and within that create a new product configuration file. The configuration file will have a splash tab where you can adjust some parameters, save and synchronize. Hope this is helpful.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This bug was marked as stalebug a while ago. Marking as worksforme. If this report is still relevant for the current release, please reopen and remove the stalebug whiteboard tag.
