This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
build 200701101900 -create EAR -start Entity from DB wizard -select tables -click next -EXCEPTION: java.io.IOException at org.netbeans.modules.j2ee.ejbjarproject.classpath.EjbJarProjectClassPathExtender.addLibraries(EjbJarProjectClassPathExtender.java:124) at org.netbeans.modules.j2ee.ejbjarproject.classpath.EjbJarProjectClassPathExtender.addLibrary(EjbJarProjectClassPathExtender.java:79) -entity classes are then correctly generated
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)