Bug 336064

Description Romain Bernard 2011-02-02 08:33:44 EST

Context : 
  - eclipse 3.6
  - subversive 0.7.9.I20101203-1700
  - use of the svn:needs-lock property (pessimistic mode)

Problem description :
When a modification on a file requires other files to change, the following exception occurs :

org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.SWT.error(Unknown Source)
at org.eclipse.swt.widgets.Widget.error(Unknown Source)
at org.eclipse.swt.widgets.Shell.<init>(Unknown Source)
at org.eclipse.swt.widgets.Shell.<init>(Unknown Source)
at org.eclipse.jface.window.Window.createShell(Unknown Source)
at org.eclipse.jface.window.Window.create(Unknown Source)
at org.eclipse.jface.dialogs.Dialog.create(Unknown Source)
at org.eclipse.team.svn.ui.dialog.DefaultDialog.create(Unknown Source)
at org.eclipse.jface.window.Window.open(Unknown Source)
at org.eclipse.jface.dialogs.MessageDialog.open(Unknown Source)
at org.eclipse.team.svn.ui.dialog.DefaultDialog.open(Unknown Source)
at org.eclipse.team.svn.ui.lock.LocksComposite.performLockAction(Unknown Source)
at org.eclipse.team.svn.ui.utility.LockProposeUtility.proposeLock(Unknown Source)
at org.eclipse.team.svn.ui.SVNTeamModificationValidator.validateEdit(Unknown Source)
at org.eclipse.team.internal.core.FileModificationValidatorManager.validateEdit(Unknown Source)
at org.eclipse.core.resources.team.FileModificationValidator.validateEdit(Unknown Source)
at org.eclipse.core.internal.resources.Workspace$5.run(Unknown Source)
at org.eclipse.core.runtime.SafeRunner.run(Unknown Source)
at org.eclipse.core.internal.resources.Workspace.validateEdit(Unknown Source)
at org.eclipse.ltk.internal.core.refactoring.Resources.makeCommittable(Unknown Source)
at org.eclipse.ltk.core.refactoring.participants.ValidateEditChecker.check(Unknown Source)
at org.eclipse.ltk.core.refactoring.participants.CheckConditionsContext.check(Unknown Source)
at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(Unknown Source)
at org.eclipse.ltk.core.refactoring.CheckConditionsOperation.run(Unknown Source)
at org.eclipse.ltk.core.refactoring.CreateChangeOperation.run(Unknown Source)
at org.eclipse.ltk.core.refactoring.PerformChangeOperation.run(Unknown Source)
at org.eclipse.core.internal.resources.Workspace.run(Unknown Source)
at org.eclipse.ltk.internal.ui.refactoring.WorkbenchRunnableAdapter.run(Unknown Source)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(Unknown Source)




/************************************************************************/
Steps to reproduce the problem :
1. Create a Java project with two classes A and B. 
2. B defines a variable of type A.
3. Put the svn:needs-lock property on all files of the Java project
4. Try to rename class A


Solution ?
We have implemented the following workaround to avoid the SWTException :
public class LockProposeUtility {
	static Status monStat = null;

	public static IStatus proposeLock(final IResource[] resources, Shell shell) {
		UIMonitorUtility.getDisplay().syncExec(new Runnable() {

			public void run() {
				Shell shell2 = null;
				List<LockResource> lockResources = LockAction
						.getLockResources(resources);
				for (Iterator<LockResource> iter = lockResources.iterator(); iter
						.hasNext();) {
					LockResource lockResource = iter.next();
					if (lockResource.getLockStatus() == LockStatusEnum.LOCALLY_LOCKED) {
						iter.remove();
					}
				}
				shell2 = UIMonitorUtility.getShell();
				IActionOperation op = LocksComposite.performLockAction(
						lockResources.toArray(new LockResource[0]), false,
						shell2);
				if (op != null) {
					UIMonitorUtility.doTaskBusyDefault(op);
					// return op.getStatus();
					monStat = (Status) op.getStatus();
					return;
				}
			}
		});
		if (monStat != null) {
			return monStat;
		}
		return Status.CANCEL_STATUS;
	}

}