Bug 150555

2) should have read
2) Reference library (in my case ojdbc14.jar) from project using REPOSITORY/ojdbc14.jar.

Created attachment 72132 [details]
jstack -l dump while hanging.

Created attachment 72133 [details]
Second jstack -l dump

After killing NB private.properties contains this line (among others):
file.reference.ojdbc14.jar=C:\\home\\a0796942\\projects\\experimental\\WebApplication4\\${var.REPOSITORY}\\oracle-10.1\\jars\\ojdbc14.jar

and the reference is broken.

Why refactoring component?

EDT is blocked by web project rename. Reassigning.

> Why refactoring?

On second thought it should have been obvious that renaming a project is fundamentally different from renaming packages,
classes and so on. Next time I am not sure I'll choose IDE.

But if the rename ran through would it leave the correct contents in project.properties?

Cheers,
Georg

Re. "deadlock" - this deadlock is not related to IDE variables. The deadlock is between Project.MUTEX and
api.java.classpath.ClassPath. Tomas, first thing which seems to me dangerous is that ClassPath.createEntries() is
calling SPI implementations while holding lock on instance of ClassPath. Is that necessary? Do you think that could be
fixed? If not then possible *workaround* would be to use AWT.invokeLater in SourceRoots.resetCache(SourceRoots.java:468).

RE. "wrong path in private.properties" - giorgio42, I would appreciate any steps how to reproduce.

Passing to Tomas for evaluation of ClassPath.createEntries().

RE. "wrong path in private.properties" - giorgio42, I would appreciate any steps how to reproduce.

Perform the steps as described, close NB, reopen NB and the project, look at nbproject/private/project.properties.

It will contain lines like these:
file.reference.ojdbc14.jar=C:\\home\\a0796942\\projects\\experimental\\WebApplication4\\${var.REPOSITORY}\\oracle-10.1\\jars\\ojdbc14.jar

instead of 
file.reference.ojdbc14.jar=${var.REPOSITORY}\\oracle-10.1\\jars\\ojdbc14.jar

Tomasi, please evaluate. Thanks

Deadlock among classpath lock and project mutex.
To dkonecny:
>first thing which seems to me dangerous is that ClassPath.createEntries() is calling SPI implementations while holding lock on instance of ClassPath
Nice idea, however completely useless. The classpath does as much as it can not to call the SPI under the lock, it splits the critical sections, uses lamport 
clocks to prevent race conditions. If you look to the code you will find out that the PathResources were collected outside of the critical section. In the critical 
section only PR.getRoots() was called which resulted in simply returning the array of URLs, but it seems that ProxyFilteringCPI.getRoots tries to acquire project 
lock. On the other side, I can use your argument that project infrastructure calls SPI code (listeners) under lock.

So what are you suggesting to do?

Re. "I can use your argument that project infrastructure calls SPI code (listeners) under lock" - true.

I will try to do a snapshot of roots where I'm doing the snapshots of PathResources (outside critical section).
But I need to test it for a while if it doesn't introduce a race condition, probably a random test is the best for this.

Make sense. Thanks.

Fixed: http://hg.netbeans.org/main/rev/e7476997924e

Integrated into 'main-golden', will be available in build *200810280201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/e7476997924e
User: Tomas Zezula <tzezula@netbeans.org>
Log: #150555:Complete hang when renaming web project using variables

I cannot reproduce the problem in trunk -> verified

The fix was backported into release65_fixes repository.

http://hg.netbeans.org/release65_fixes/rev/a7f1190c8886

verified in patch 1