Bugzilla – Full Text Bug Listing
| Summary: | [ViewMgmt] Reinstalling eclipse but reusing workspace gives "could not find view" error | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Dave Nice <dave> | ||||||
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> | ||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | daniel_megert, emoffatt, ob1.eclipse, pwebster, remy.suen | ||||||
| Version: | 3.6.1 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | stalebug | ||||||||
| Attachments: |
|
||||||||
|
Description
Dave Nice
>This bug occurs in my Eclipse RCP product, which is where I care about it being
>fixed, but I can reproduce with basic Eclipse, too.
I cannot reproduce this with plain Eclipse SDK. Can you please provide the exact steps that you use to reproduce this using the Eclipse SDK?
Dani, Thanks for engaging with this problem. I apologise that you couldn't recreate - in an attempt to keep my description as simple as possible I must have missed something crucial. 1. I create a plugin called Test. When prompted, I use "RCP application with a view" 2. I create a feature called TestFeature which has the Test plugin as a dependency 3. I export this feature as an archive update site (which I attach to this bug - testfeature.zip) 4. I unzip eclipse 3.6.1 into the directory eclipse361 5. I run ./eclipse361/eclipse -data workspace1 6. I install TestFeature from my archive update site 7. I am automatically prompted to restart, and do so. 8. I am in the Java perspective. I open the "View" view 9. I switch to the Debug perspective 8. I close eclipse. 8. I delete the eclipse361 directory 9. I recreate the eclipse361 directory from my SDK zip 10. I start eclipse again, using the original workspace - ./eclipse361/eclipse -data workspace1 11. I install TestFeature again 12. I restart when prompted <- after this step, the view gets marked removed="true" in workbench.xml 13. I switch to the Java perspective 14. I receive the error: "Unable to read workbench state. Reason: Problems occurred restoring perspective. Could not find view: Test.view" Do shout if you need any more information. This has been around since at least Eclipse 3.4 and makes it difficult to migrate seamlessly to a new version of Eclipse if using the update mechanism isn't an option. Created attachment 192797 [details]
Testcase - feature including sample plugin with RCP view
OK, I've just tried the following: 1) Create a new project using the 'With a View' template 2) Start a fresh inner, the sample view is shown 3) Open the Debug perspective and open the 'Sample View' 4) Exit the inner Now, close the project implementing the Sample View and restart the inner: Notice that the Sample View is gone (silently) from the Debug Perspective. When you click on the java Perspective you get the error dialog as described in the bug description. In neither case is the perspective reset (i.e. other than removing the view it's the same one you closed with). This difference may just be the value used for the status handler (SHOW vs LOG) but IMO neither of these is the desired behavior; right now we show the user an 'Error Part' if an exception is thrown while the part is being created, it seems as if this would be the correct behavior here as well (i.e. the view would continue to show up as the Error Part until the fragment is re-installed and would then revert back to the real view implementation. BTW, I've also tried the following: run once with the Sample View open close the project and restart (get error) close the session, open the project and restart In this scenario I could successfully re-open Sample View so at least the removed=true doesn't seem to be permanent...;-). (In reply to comment #4) > <snip> > BTW, I've also tried the following: > > run once with the Sample View open > close the project and restart (get error) > close the session, open the project and restart > > In this scenario I could successfully re-open Sample View so at least the > removed=true doesn't seem to be permanent...;-). Hi Eric, Thanks for having a try to recreate! This 2nd option sounds the closest to my scenario. I agree that the removed=true seems to get resolved eventually, I'm not sure whether the removed attribute disappears, or the view entry gets deleted and recreated when you reopen. Either way, the main issue is the error message and the fact that to get the views back you either need to manually re-open or reset perspective (when in fact the views were already re-installed). Cheers Created attachment 193090 [details]
Patch to LOG the failure rather than putting up the ErrorDialog
This is not really a fix to the basic issue but rather it just makes the case where the 'not found' view is in a background perspective on start consistent with what happens if the view is in the initially visible perspective (i.e. in both cases the PartInitException is logged and the view removed from the presentation.
I did do some digging to see whether it's feasible to move to the preferred 'ErrorPart' approach but the problem we're seeing is handled in the Perspective's 'restoreState' method, long before we ever attempt to create the view itself... This is bad news as messing persistence code is not something we like to do late in any development cycle... If getting rid of the actual dialog is of any use to you we could consider adding the patch into M7... Hi Eric, Thanks. Bit of a toss-up with the dialog - on the one hand it alerts the user to the fact that something's gone wrong (so they can take action like resetting the perspective) but on the other hand it's likely to cause end-user panic :-) I'll have a think and get back to you on that. Just to confirm - you're saying that currently you can't see a way of avoiding the need to reset the perspective (or reopen the views)? One thing that confuses me is why I can't really find any record of other people hitting this - it seems like it should be pretty common! Thanks again, Dave (In reply to comment #8) > One thing that confuses me is why I can't really find any record of other > people hitting this - it seems like it should be pretty common! It seems to be fairly uncommon, but we have looked at this before. See bug 218197. When it does happen (the replace case as opposed to the update case) our policy was to make the view disappear, and people just re-open their views. PW In the scenario I was testing with I never had to reset the perspective...if the bundle was available I just had to re-open the view. (In reply to comment #10) > In the scenario I was testing with I never had to reset the perspective...if > the bundle was available I just had to re-open the view. Hi Eric, Correct - that is one way of doing it. We're getting a number of views removed for each perspective, so reopening is a bit of a faff - resetting is the better option for us. I think we'll stick with the error box for now - at least it's clear what's happened. Thanks again, Dave 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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. |