Created attachment 37257 [details]
IOE

I can reproduce this issue onlo for the first time generating entity with clean
userdir

I can't reproduce even when starting with a clean userdir. The exception is
thrown by ant/project, reassigning there.

Not sure if this will be picked up by M6 or M7. Anyway not known to be
reproducible, so don't know if the fix works.

Checking in AntProjectHelper.java;
/shared/data/ccvs/repository/ant/project/src/org/netbeans/spi/project/support/ant/AntProjectHelper.java,v
 <--  AntProjectHelper.java
new revision: 1.41; previous revision: 1.40
done

*** Issue 92810 has been marked as a duplicate of this issue. ***

v

I can reproduce it again in the build 200702041900 with slightly different steps.
-create WebApplication (j2ee 1.4 for tomcat)
-start Entity from DB wizard
-select tables
-click Next:
-EXCEPTION: java.io.IOException
	at
org.netbeans.modules.web.project.classpath.WebProjectClassPathExtender.addLibraries(WebProjectClassPathExtender.java:125)
	at
org.netbeans.modules.web.project.classpath.WebProjectClassPathExtender.addLibrary(WebProjectClassPathExtender.java:81)

attaching fresh stacktrace

Created attachment 38090 [details]
IOE

I've successfully reproduced this issue in same build vit one difference -
exception occured not when I clicked next but when I clicked Create Persistence
unit on next page.

since this is reproducible on more machinse I'm increasing priority and marking as M7 stopper

I can reproduce in current sources:

- run IDE on fresh user dir

- make sure there is a usable sample table. In the IDE downloads this seems to
happen automatically, but in my source build it did not, so: build the
db/derby/bundled module, select Tools > Java DB Database in IDE, create new DB
somewhere, create one table with arbitrary contents

- create new web app, uncheck Source Level 1.4 box

- File | New, Persistence | Entity Classes from Database

- select DB connection and some table, add it, click Next

- click Create Persistence Unit and hit Enter

Now for analysis. After setting breakpoints on all lines in
AntProjectHelper.java which iterate or modify modifiedMetadataPaths:

modifiedMetadataPaths.add(path); // modifying()
modifiedMetadataPaths.add(PROJECT_XML_PATH); // markModified()
Iterator<String> it = modifiedMetadataPaths.iterator(); // save()
it.remove(); // save()
modifiedMetadataPaths.add(PROJECT_XML_PATH); // save()

then you see that project.xml, project.properties, and private.properties are
added to the set, as expected, and save is called. In

locks.add(properties.write(path));

you then hit a breakpoint again:

AntProjectHelper.modifying line: 489
AntProjectHelper.access$1100 line: 69
AntProjectHelper$13.run line: 879
AntProjectHelper$13.run line: 853
Mutex.writeAccess line: 321
AntProjectHelper.putConfigurationFragment line: 852
AntProjectHelper.putPrimaryConfigurationData line: 758
ClassPathSupport.putIncludedLibraries line: 340
ClassPathSupport.encodeToStrings line: 238
WebProjectClassPathExtender$4.run line: 273
Mutex.leaveImpl line: 810
Mutex.leave line: 743
Mutex.readAccess line: 232
ProjectProperties$PP.fireChange line: 333
ProjectProperties$PP.diskChange line: 352
ProjectProperties$PP.fileModified line: 367
FileChangeSupport$Holder.someChange line: 155
FileChangeSupport$Holder.fileChanged line: 170
FCLSupport.dispatchEvent line: 81
FileObject$ED.dispatch line: 856
EventControl.invokeDispatchers line: 181
EventControl.exitAtomicAction line: 155
EventControl.runAtomicAction line: 100
FileSystem.runAtomicAction line: 471
ProjectProperties$PP.write line: 215
ProjectProperties.write line: 121
AntProjectHelper.save line: 565
AntProjectHelper.access$100 line: 69
AntProjectHelper$1.save line: 107
AntBasedProjectFactorySingleton.saveProject line: 191
ProjectManager$6.run line: 560
ProjectManager$6.run line: 554
Mutex.writeAccess line: 357
ProjectManager.saveProject line: 553
WebProjectClassPathExtender$1.run line: 113
Mutex.writeAccess line: 357
WebProjectClassPathExtender.addLibraries line: 87
WebProjectClassPathExtender.addLibrary line: 81
Util.addLibraryToProject line: 468
Util.buildPersistenceUnitUsingWizard line: 425
EntityClassesPanel.createPUButtonActionPerformed line: 393
[...EQ...]

What is happening here? Various code is in ProjectManager.mutex write access to
begin with: WebProjectClassPathExtender.addLibraries initially, and of course
ProjectManager.saveProject reenters it to be sure. After writing the modified
properties file, ProjectProperties$PP.fireChange is called and it notifies
listeners synchronously in read access, as expected. This presumably is
indirectly notifying WebProjectClassPathExtender.propertyChange (I did not see
this stack, just guessing), which calls storeLibLocations. That posts a task in
postWriteRequest. What is weird is that this task is run not after the top-level
mutex write access (from WPCPE.aL) is exited, but at the end of Mutex.readAccess
inside the write access! However strange, the Javadoc seems to back this up:

"This request runs immediately iff this Mutex is in the "pure" exclusive mode,
i.e. this Mutex is not reentered in shared mode after the exclusive mode was
acquired. Otherwise it is delayed until all read requests are executed."

I must conclude that the use of postWriteRequest inside a project system
listener is simply wrong. Anyway the request uses RequestProcessor to actually
do the saving, so the whole block can be moved into RP.

Created attachment 38154 [details]
Suggested patch; seems to solve the CME, but results in an apparently independent deadlock (issue #94807)

"but at the end of Mutex.readAccess inside the write access!"
Yes, this is expected and correct behaviour. post*access are meant to perform as
soon as the "other" access finishes, that is, to perform the write as soon as
read (in current thread and also all the other threads) is left. postRead under
read performs immediatelly and so does postWrite under write.

The simplest explanation would probably be that post{Read|Write}Request behaves
the same as {read|write}Access except in the case _current_ thread holds the
opposite access. Then it "delays" the execution.

Generally I find the behavior of post*Request to be confusing and as a rule
these methods should never be used. At least, I have spent a lot of time working
with Mutex and I do not think I have ever found a legitimate use for them.
Certainly my expectation when I have write access and call some code in read
access is that that foreign code cannot mutate anything - but it can, if it
calls postWriteAccess. Also I have never heard of methods with comparable
semantics in any other read-write lock API.

BTW in this issue I forgot to mention before that it is pretty strange that some
code in web/project changes some project metadata and saves it - after which the
very same class gets notified of the changes, and reacts by making some more
changes and asking them to save later! Probably there is some logic error in the
listener logic. Perhaps the listener should simply be disabled while the write
operations are taking place? (Listeners are notified synchronously, so a simple
boolean flag guarded by a try-finally block would suffice.) Or if the second set
of metadata changes are in fact valuable, probably they should made to begin with.

The second set of metadata is needed by build-impl.xml to copy the libraries on
the compilation classpath to the WAR file without employing a custom Ant task.
The metadata need to be computed every time the compilation classpath changes,
not only the changes are made through ProjectClassPathExtender. The listener
could have been in any other place, it seems it was just convenient for the
person who wrote this code to put it in WPCPE.

Probably we could both disable the listener and compute and store the metadata
in the addXyz() methods, but does it bring any advantage? The listener needs to
stay there anyway to handle external changes to the classpath.

Well, if the listener is really independent, then consider the original patch I
attached (but fix the deadlock I filed first).

Fixed. Proposed fix applied also in ejb project.

Checking in
j2ee/ejbjarproject/src/org/netbeans/modules/j2ee/ejbjarproject/classpath/EjbJarProjectClassPathExtender.java;
/cvs/j2ee/ejbjarproject/src/org/netbeans/modules/j2ee/ejbjarproject/classpath/EjbJarProjectClassPathExtender.java,v
 <--  EjbJarProjectClassPathExtender.java
new revision: 1.11; previous revision: 1.10
done
Checking in
j2ee/ejbjarproject/src/org/netbeans/modules/j2ee/ejbjarproject/classpath/SourcePathImplementation.java;
/cvs/j2ee/ejbjarproject/src/org/netbeans/modules/j2ee/ejbjarproject/classpath/SourcePathImplementation.java,v
 <--  SourcePathImplementation.java
new revision: 1.5; previous revision: 1.4
done
Checking in
web/project/src/org/netbeans/modules/web/project/classpath/WebProjectClassPathExtender.java;
/cvs/web/project/src/org/netbeans/modules/web/project/classpath/WebProjectClassPathExtender.java,v
 <--  WebProjectClassPathExtender.java
new revision: 1.16; previous revision: 1.15
done
Checking in
web/project/src/org/netbeans/modules/web/project/classpath/SourcePathImplementation.java;
/cvs/web/project/src/org/netbeans/modules/web/project/classpath/SourcePathImplementation.java,v
 <--  SourcePathImplementation.java
new revision: 1.11; previous revision: 1.10
done

*** Issue 92852 has been marked as a duplicate of this issue. ***

Please also fix the appclient project type.

As you wish.

Checking in AppClientProjectClassPathExtender.java;
/cvs/j2ee/clientproject/src/org/netbeans/modules/j2ee/clientproject/classpath/AppClientProjectClassPathExtender.java,v
 <--  AppClientProjectClassPathExtender.java
new revision: 1.3; previous revision: 1.2
done
Checking in SourcePathImplementation.java;
/cvs/j2ee/clientproject/src/org/netbeans/modules/j2ee/clientproject/classpath/SourcePathImplementation.java,v
 <--  SourcePathImplementation.java
new revision: 1.3; previous revision: 1.2
done

*** Issue 94303 has been marked as a duplicate of this issue. ***

Wokrs fine, no previous symptoms ... V.

Product Version: NetBeans IDE Dev (Build 200809170201)
Java: 1.6.0_10-beta; Java HotSpot(TM) Client VM 11.0-b11
System: Linux version 2.6.24-19-generic running on i386; UTF-8; en_US (nb)