Bugzilla – Full Text Bug Listing
| Summary: | NPE with extensibleSpashHandler extension | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Thomas Kratz <eiswind> | ||||
| Component: | UI | Assignee: | Paul Webster <pwebster> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ChrisAustin, pinnamur, pwebster | ||||
| Version: | 4.1 | ||||||
| Target Milestone: | 4.2.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Thomas Kratz
I will try to look into this. Rational is also running into this problem. We use a common splash screen for nearly all of our products, and calling AbstractUIPlugin.imageDescriptorFromPlugin() throws an NPE because e4context is null. It's possible to add a null check and probably replicated the same code for ISharedImages that's in the org.eclipse.ui.internal.WorkbenchPlugin.initializeContext(IEclipseContext) method called later. I'd accept a patch. PW A check for null is a good idea, but I don't think I understand the rest of your comment. Is there still a way we can retrieve an image during the splash screen load? I think we could have the code try e4Context first, but if it's null and the local var is null, fall back to:
if (sharedImages == null) {
sharedImages = new SharedImages();
}
return sharedImages;
PW
Created attachment 224736 [details]
Patch to create sharedImages on demand
Paul, is this going to result in two copies of the shared images since we're going to eventually add another instance when we set up the context ? Is there any way to delay the ExtensibleSplashHandler until after the e4Context has been initialized, this would be the 'correct' fix IMO. (In reply to comment #7) > Paul, is this going to result in two copies of the shared images since we're > going to eventually add another instance when we set up the context ? No, our context setup is done in such a way that there will only be on SharedImages registry. PW To be honest, I was still a little confused by the potential fix, because the images we need at splash screen time are not SharedImages, they are icons we ship in our product plugins. I was planning to actually avoid the call by using ImageDescriptor.createFromURL(), which doesn't throw an NPE. The only question about this approach is whether ImageDescriptor.createFromURL() handles nl images (but I understand that is a little off-topic). (In reply to comment #9) > To be honest, I was still a little confused by the potential fix, because > the images we need at splash screen time are not SharedImages, they are > icons we ship in our product plugins. The problem you're seeing is that AbstractUIPlugin.imageDescriptorFromPlugin(*) is checking ISharedImages. It's one of the locations we can load images from, but it's not relevant for your call. You're just hitting it to early in the startup cycle and our slightly re-configured loading wasn't ready yet. The fix will make it the ISharedImages check a no-op as far as you're concerned, which is what you get in 3.x. > > I was planning to actually avoid the call by using > ImageDescriptor.createFromURL(), which doesn't throw an NPE. > The only question about this approach is whether > ImageDescriptor.createFromURL() handles nl images (but I understand that is > a little off-topic). I'm not sure this'll handle the $nl$, but it might for platform:/plugin URLs (support for that was added a while ago). PW (In reply to comment #6) > Created attachment 224736 [details] > Patch to create sharedImages on demand Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?h=R4_2_maintenance&id=c4c9b9c6cd031d5bd96a5b85a44fb8e498725184 Thanx Jens. PW In M20130116-1800 PW . |