Community
Participate
Working Groups
eclipse-e4-SDK-incubation-I20100114-2115-win32.zip 1. Start the demo. 2. Make an album. 3. Close the demo. 4. Copy an image that has exif data over to the created album (see bug 263898). 5. Restart the demo. 6. Click the album, the thumbnails show are rendered. 7. Switch to the 'Exif' view. The table is populated. 8. Close the demo. 9. Restart the demo. 10. The 'Exif' view is empty, this is expected. 11. Select the album. The 'Exif' view remains empty. 12. Switch to the 'Thumbnails' view. This view is populated.
Unrelated to perspectives. I thought it was when I made the report. Forgot to edit the summary when I realized it wasn't.
(In reply to comment #0) > eclipse-e4-SDK-incubation-I20100114-2115-win32.zip > > 1. Start the demo. > 2. Make an album. > 3. Close the demo. > 4. Copy an image that has exif data over to the created album (see bug 263898). > 5. Restart the demo. 6. Activate the 'Exif' view. 7. Click the album. The 'Exif' view is not populated. Even worse... :/
The @Inject annotation for the ExifTable's IEventBroker seems to be the cause. If I remove the annotation then selection changes appear to be received properly. Sounds crazy but this is what I'm seeing.
Created attachment 156239 [details] Tests patch to reproduce the problem Pretty straightforward test. Comment out the @Inject to get it to pass.
Created attachment 156243 [details] Tests patch to reproduce the problem v2 This test is better as it doesn't depend on the event broker. The "chaining" on injections seems to be causing problems. Please look at lines 31 and lines 48.
Created attachment 156246 [details] Workaround patch This patch changes ExifTable to work around the problem. It has been released to HEAD.
The problem is in the TrackableComputationExt#hashCode() : both "outer" computation that makes Exif part and the "inner" computation have the same runnable. The hashCode() evaluates to the same value, and by the time "outer" listener is added, there is the listener with the same has code in the HashSet from the "inner" computation.
This turns out to be a non-trivial problem. The "simple" fix would be to remove #equals() and #hasCode() overrides on the TrackableComputation, TrackableComputationExt, and ValueComputation. But I am not sure if that is the "right" fix...
Can't really think of a better summary but I figured I'd change it to something that half described the bug in question.
Created attachment 156441 [details] Fix The patch merges lists of dependent names for context listeners for listeners that have "equal" listsners already added to the context. (Context injection creates runnables based on the context [ObjectProviderContext]; both "outer" and "inner" #make() calls are "equals" as #equal() overrides take only runnable in account and ignore dependents lists. The solution in this pacth is to merge dependent context/names lists.) (The simple solution of removing #equals() overrides does not work as other calculations rely on the runnable being added only once to the listener list. Ignoring that causes duplicate entries added when, say, a dependent entry is removed from a parent context.)
Patch "Fix" and Remy's test patch applied to CVS Head. I'll reverse change to the ExifTable from "Workaround Patch" as I merge my other work for that bundle. Thank you for finding this out - this certainly was the weirdest bug I've seen so far for the context injection.
(In reply to comment #11) > Patch "Fix" and Remy's test patch applied to CVS Head. Awesome, thanks Oleg. > I'll reverse change to > the ExifTable from "Workaround Patch" as I merge my other work for that bundle. Sounds good to me. > Thank you for finding this out - this certainly was the weirdest bug I've seen > so far for the context injection. Yeah, this one was really weird. ;)
