Community
Participate
Working Groups
In case plugin.xml is not under version control but the project itself is, the generation of plugin jars via popup fails with "Invalid thread access" from SWT. The reason is, that BuildPluginAction.enusre wants to show an error after finding out that there are problems with plugin.xml.
The problem is that PDE is logging exception in non-GUI thread. It should not do that. Here is the offending code: IRunnableWithProgress op = new IRunnableWithProgress() { public void run(IProgressMonitor monitor) { IWorkspaceRunnable wop = new IWorkspaceRunnable() { public void run(IProgressMonitor monitor) throws CoreException { try { doBuildPlugin(monitor); } catch (InvocationTargetException e) { PDEPlugin.logException(e); } } }; try { PDEPlugin.getWorkspace().run(wop, monitor); } catch (CoreException e) { PDEPlugin.logException(e); } } }; Recommended fix: try/catch block within the operation should not call 'logException' at all. It should take CoreException, wrap it in InvocationTargetException and rethrow it. The actual code to logException (that may also open an error dialog) is already in the main code that runs the operation and that code is running in the GUI thread. F4 candidate: Value: Medium - confusing when an operation fails and also fails to tell why it failed due to the SWT error. Risk: Low - the proposed error handling pattern is already used everywhere in PDE.
Fixed
Not fixed!! The current code in HEAD has two problems: 1) Method 'ensureValid' calls 'getActiveWorkbenchShell' that returns null when called from within the wizard. IMarker[] markers = featureFile.findMarkers(IMarker.PROBLEM, true, IResource.DEPTH_ZERO); if (markers.length > 0) { // There are errors against this file - abort String message; message = PDEPlugin.getResourceString (KEY_ERRORS_MESSAGE); MessageDialog.openError( This ---> PDEPlugin.getActiveWorkbenchShell(), PDEPlugin.getResourceString(KEY_ERRORS_TITLE), message); return false; } The fix for this is to pass 'null' instead (openError method can work with null) 2) Method 'syncLogException' fails with NPE because of the same problem. private void syncLogException(final Throwable e) { this ----> final Display display = PDEPlugin.getActiveWorkbenchShell ().getDisplay(); display.syncExec(new Runnable() { public void run() { PDEPlugin.logException(e); } }); } The proposed fix is to use SWTUtil.getStandardDisplay that is implemented as follows: public static Display getStandardDisplay() { Display display; display = Display.getCurrent(); if (display == null) display = Display.getDefault(); return display; } If this method returns null, exception will only be logged (no error message). Just logging the error does not require being in the GUI thread. If not approved for fixing, the bug will show up every time one of the following happens: 1) There are error markers agains the plug-in project or its children 2) Build script creation fails with a CoreException. We should consider fixing this (again!) for 2.0 because users are not informed about the primary problem due to the secondary exception in the problem-reporting code.
*** Bug 20917 has been marked as a duplicate of this bug. ***
Yet another problem with 'ensureValid': it should not block the build if there are any 'PROBLEM' markers associated with the plug-ins project. It should only care for errors, not warnings or infos. In particular, infos markers crated by Team (e.g. "Not under CVS control" variety) should not prevent plug-in build. See bug #20148.
Risk: Small, code is in hand Effort: Small, code is in hand
Fixed in GM3
