Created attachment 23119 [details]
threaddump

The classes were correctly moved.

Fix can be done in PackageViewChildren by rescheduling fileDelete event handler.
Petre, please take a look at it. Thanks.

I know that we agreed on fixing (better said workarounding) this in
PackageViewChildren. However we looked at it with Jarda and we found out that
the real fix should be done in the RefactoringSession.doRefactoring() method.
The functionality of the method should be put into ActomicAction and posted into
fs.runAtomicAction(...); After doing this all the events from filesystem will be
fired after the changes are done and the deadlock should not occur. This fix
should then work for all refactorings.

Reassigning back and adding Jarda to cc.

It is not that easy. Javacore's UndoManager expects, that all FileEvents fired
outside of MDR transaction are not generated by javacore. UndoManager will not
work after suggested change, because *all* FileEvents will be fired outside of
MDR transaction in case of rafctoring.

We can still make it work. There is a way to distinguish from which 
AtomicAction an event is fired. See  
http://www.netbeans.org/download/dev/javadoc/org-openide-filesystems/org/openide/filesystems/FileEvent.html#firedFrom(org.openide.filesystems.FileSystem.AtomicAction) 
 
The check is based on equals, so if you write: 
 
class MySpecialAtomicAction implements FS.AtomicAction { 
  public static MySpecialAtomicAction DEFAULT = new 
MySpecialAtomicAction(null); 
 
  private AtomicAction delegate; 
 
  public MySpecialAtomicAction(AtomicAction a) { 
    this.delegate = a; 
  } 
  public void run() throws IOException { 
    delegate.run(); 
  } 
  public int hashCode() { 
    return getClass().hashCode(); 
  } 
  public boolean equals(Object o) { 
    return getClass().equals(o.getClass()); 
  } 
} 
 
and use this one to do the refactorings, then the undo manager can use 
fileEvent.firedFrom(MySpecialAtomicAction.DEFAULT) you will get true if the 
event originated from your transaction, even if the transaction is already 
over. 
 

If I understand it well, you suggest to introduce new API class
MySpecialAtomicAction into javacore module and introduce new pattern, that all
javamodel users should do their changes inside this AtomicAction?

Well, no or maybe.   
  
1. No because: I want you to wrap the call to  
org.netbeans.mdr.NBMDRepositoryImpl.endTrans(NBMDRepositoryImpl.java:248)  
at org.netbeans.modules.refactoring.api.RefactoringSession.doRefactoring with  
an AtomicAction that you then successfully recognize in undoredo manager.  
  
2. Maybe because: the undoredo manager and RefactoringSession is in different  
package and they need to communicate. Then an api could be needed.  
 
3. One more No because: this gets down to "all FileEvents fired outside of MDR 
transaction are not generated by javacore" - if I remember right, javacore 
methods always acquire MDR transaction (if it has not been already acquired). 
If true, then the only needed thing is to also start AtomicAction in these 
methods[1]. This will work as AtomicActions can be nested and an event returns 
true from firedFrom for all active at the time of creation.  
 
Imho you can either fix this deadlock by doing #1 and #2 with a special 
communication between refactoring and javamodel, or you can try to provide an 
API for everyone to do the same, like the one described in #3. 
 
[1] I agree that this is easier to say than to do, the diff is going to be 
really big... 

This deadlock occured only with jemmy module enabled.

The deadlock can be easily simulated with regular modules in 5.0 IDE. 

OK. What to do whith this issue?
We definitely don't want to implement solution Jarda suggested. It might be
correct, but it is too risky and potentially can introduce regressions, which
will be worse than this issue itself.
So - is it possible to implement original workaround, we discussed with Hrebejk?
Thanks for any help.

We agreed, that fix proposed by Jarda is too risky in this phase of
developement. Hrebejku, please try to implement workaround in PackageViewChildren.
BTW this deadlock was reported only once so far.

Re-assigning...

Created attachment 27185 [details]
Proposed fix.

Tomas, per our previous agreement, could you please review the patch and apply
it? Thanks.

Checking in
project/src/org/netbeans/spi/java/project/support/ui/PackageViewChildren.java;
/cvs/java/project/src/org/netbeans/spi/java/project/support/ui/PackageViewChildren.java,v
 <--  PackageViewChildren.java
new revision: 1.66; previous revision: 1.65
done

verified