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.
GlassFish v2ur2, NetBeans 6.5, Windows 2000 After you undeploy an enterprise project that has a web module and an ejb module, you cannot delete some of the jar files. Glassfish still keeps them open. This has a severe impact when you want to rebuild a project because the build script fails: Example: nbproject\build-impl.xml:398: Unable to delete file dist\gfdeploy\Member-war_war\WEB-INF\lib\wicket-extensions-1.3.5.jar You can reproduce this as follows: 1) Deploy an enterprise application. 2) Un-deploy it 3) Try to delete the build and dist directories from the enterprise app, the web module and the ejb module At least on one of the jar files, there is a sharing violation because the file is in use. The problem disappears when the server is stopped. I get this all the time and now while I write this. In my case the enterprise app is the only app/module that was deployed on the server. With all the other errors that I am getting with invalid breakpoints due to stale old java classes in debugging sessions, I ask myself how it is possible to develop enterprise software with NetBeans and Glassfish.
A J2EE issue, nothing to do with debugger.
I will investigate.
One note... Windows 2000 is not a supported platform... see http://www.netbeans.org/community/releases/65/relnotes.html#supported_technologies
I can replicate this issue. I used the tool described here: http://blogs.sun.com/quinn/entry/tool_for_diagnosing_failed_glassfish and got the following output... >show Current list of opened but unclosed jar files matching the filter: Path "C:\Users\vbk\Documents\NetBeansProjects\EnterpriseApplication9\dist\gfdepl oy\EnterpriseApplication9-war_war\WEB-INF\lib\wicket-1.4-rc1.jar" ..Opened by hashCode object 216 from: java.util.jar.JarFile.<init>(java\util\jar\JarFile.java:135) java.util.jar.JarFile.<init>(java\util\jar\JarFile.java:97) com.sun.enterprise.deployment.annotation.impl.ModuleScanner.addScanJar(com\sun\enterprise\deployment\annotation\impl\ModuleScanner.java:85) com.sun.enterprise.deployment.annotation.impl.WarScanner.<init>(com\sun\enterprise\deployment\annotation\impl\WarScanner.java:101) com.sun.enterprise.deployment.annotation.factory.ScannerFactory.createScanner(com\sun\enterprise\deployment\annotation\factory\ScannerFactory.java:78) com.sun.enterprise.deployment.archivist.Archivist.processAnnotations(com\sun\enterprise\deployment\archivist\Archivist.java:403) com.sun.enterprise.deployment.archivist.Archivist.readAnnotations(com\sun\enterprise\deployment\archivist\Archivist.java:346) com.sun.enterprise.deployment.archivist.Archivist.readDeploymentDescriptors(com\sun\enterprise\deployment\archivist\Archivist.java:318) com.sun.enterprise.deployment.archivist.Archivist.open(com\sun\enterprise\deployment\archivist\Archivist.java:213) com.sun.enterprise.deployment.archivist.ApplicationArchivist.readModulesDescriptors(com\sun\enterprise\deployment\archivist\ApplicationArchivist.java:321) com.sun.enterprise.deployment.backend.Deployer.loadDescriptors(com\sun\enterprise\deployment\backend\Deployer.java:338) com.sun.enterprise.deployment.backend.AppDeployerBase.loadDescriptors(com\sun\enterprise\deployment\backend\AppDeployerBase.java:358) com.sun.enterprise.deployment.backend.AppDeployer.deploy(com\sun\enterprise\deployment\backend\AppDeployer.java:226) com.sun.enterprise.deployment.backend.AppDeployer.doRequestFinish(com\sun\enterprise\deployment\backend\AppDeployer.java:148) com.sun.enterprise.deployment.phasing.J2EECPhase.runPhase(com\sun\enterprise\deployment\phasing\J2EECPhase.java:191) com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(com\sun\enterprise\deployment\phasing\DeploymentPhase.java:108) com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(com\sun\enterprise\deployment\phasing\PEDeploymentService.java:919) com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(com\sun\enterprise\deployment\phasing\PEDeploymentService.java:279) com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(com\sun\enterprise\deployment\phasing\PEDeploymentService.java:788) com.sun.enterprise.management.deploy.DeployThread.deploy(com\sun\enterprise\management\deploy\DeployThread.java:187) com.sun.enterprise.management.deploy.DeployThread.run(com\sun\enterprise\management\deploy\DeployThread.java:223) I opened an issue in the GF issue tracker https://glassfish.dev.java.net/issues/show_bug.cgi?id=6994
Note: switched to v2.1 b60e and could not reproduce this issue. Marking as worksforme, since there is no plugin code change to account for this. Please re-open this issue if you can reproduce it while using a promoted build of v2.1
Hi, My apologies for re-opening this issue. I went through a high number of build cycles while trying to create a project from the src/wicket-examples folder in the wicket 1.4 RC6 http://www.apache.org/dyn/closer.cgi/wicket/1.4-rc6 The most stressful problem was that I was not able to clean the project due to this error: Deleting directory ... build-impl.xml:852: Unable to delete file ...build\web\WEB-INF\lib\wicket-1.4-rc6.jar ... This is exactly the same error I had before. In addition to leaving this in the priority 1 category, I would like to say that the edit-compile-run/debug cycle should not have THIS type of issue because it makes hell out of a developer's life. One tends to press forward, building the project, ignoring that the clean did not work. What actually happen is that other old libraries do not get deleted either, and new errors occur that do not have an explanation. All this can happen easily if libraries are removed from the project. I am not even concerned about another error: stale parsing results. I have a project now that has the "!" icon in the source code folder while no source file is identified as having an error. By the way if you are looking for a usability test of NetBeans, I would recommend to use a computer of average speed and try wicket-examples by starting a new project with only copying the directories src/main/java and src/main/webapp. While trying to build and run the project (admittedly this is not very efficient) one will let the IDE discover the missing libraries and create and add them one by one. At the end I lost patience and removed all velocity related code (which caused this error to re-surface). But anyway, it shows how the IDE deals with the changes (such as moving source packages out of the reach of the IDE, using the operating system) and the constant scanning due to the addition of libraries. At various stages the IDE started to hang with 100% CPU during a manual deploy and I had to kill it. It took me about a day to get there, including the searching and downloading of the libraries. I would like to share an interesting observation. I had two different version of the same package in the path (portlet api 1.0 and 2.0). The IDE clearly shows this via duplicate class names with Menu|Navigate|Go to Type. But a stressed-out developer will not necessarily discover this. It would be very valuable to have a mechanism that warns of any duplicate classes in the class path. I have seen this in compilers before.
which build of glassfish are you using? which version of the IDE are you using? Are you still running on Win2k or have you updated the OS to a more recent release? which jdk are you using for the server?
Hi, I think all info is in the Help|About box: Product Version: NetBeans IDE 6.7 (Build 200906241340) Java: 1.6.0_06; Java HotSpot(TM) Client VM 10.0-b22 System: Windows 2000 version 5.0 running on x86; Cp1252; en_NZ (nb) Userdir: D:\Documents and Settings\Administrator\.netbeans\6.7 The server runs on the same JDK as the IDE. I don't know the server build number - its version is 2.1. It is the one bundled with the IDE. I deleted the old server before installing the 6.7 IDE. I got the error first time before the application was first started successfully.
Thanks for supplying the info... one clarification request Is win2k v5 really the fifth release of win2k or is there a more common name used in the marketplace for the OS that you are using (like Vista)?
Microsoft (R) Windows Version 5.0 (build 2195: Service Pack 4) I think Windows 2000 is the brand name for Windows version 5, same as Windows NT was the brand name for Windows version 4. That is all I know. I can reproduce this bug every time like this: init: undeploy-clean: Undeploying ... While undeploying, trying to stop application in target server completed successfully While undeploying, trying to remove reference for application in target server completed successfully Undeploying the application Trying to undeploy application from domain completed successfully Undeployment of application Wicket_Examples completed successfully All operations completed successfully deps-clean: do-clean: Deleting directory ...\build ...\nbproject\build-impl.xml:852: Unable to delete file ...\build\web\WEB-INF\lib\wicket-1.4-rc6.jar BUILD FAILED (total time: 13 seconds) It looks like the jar file is left open. In the services window, server node, the application is no longer shown (deployed). Trying to delete the build, dist directories under Windows: "Error deleting file or folder" "Cannot delete wicket-1.4-rc6: There has been a sharing violation." "The source or destination file may be in use" Tis applies to multiple files: ...\build\web\WEB-INF\lib\wicket-extensions-1.4-rc6.jar ...\build\web\WEB-INF\lib\wicket-devutils-1.4-rc6.jar ...\build\web\WEB-INF\lib\wicket-1.4-rc6.jar After I undeploy from the services window (not clean from Projects window), I get the same error when trying to delete the build, dist directories.
There is the possibility that wicket is opening the jar (from your app) and not releasing it... You may want to read/run through this http://blogs.sun.com/quinn/entry/tool_for_diagnosing_failed_glassfish to see what part of the server or app is calling open...
Created attachment 84645 [details] Testcase reproduces on Win2k and Win XP
Hi, Many thanks for the link to the diagnostics tool. I have to get some sleep now and won't be able work on this for a while. I have spent all my time to shrink the Wicket examples to a testcase. That only requires very few downloadable libraries to run. Could you use the tool to examine this testcase? Best regards
I was able to replicate this behavior. I reopened the issue against GF. while we wait for the server side of this issue to get attention, there is a work-around that might be useful to you.... copy the jars for wicket into the app server's lib directory... You will not need to have these jars in the war files, and they will not need to be deleted when you do a clean. since there is a work-around, I am going to lower the priority to p2.
I just did a test of a wicket sample deployed against GF v3 build 54. I ran the app and then did a clean, which was successful. The same app reproduced your issue when I deployed it to v2.1... Since the app that is holding the reference to the jar file is the server, there is little the IDE or the plugin can do to prevent this issue from happening. In NB 6.8, v3 will ship as the 'bundled' server, so from one perspective, this issue could be closed as 'FIXED'... I ma not going to do that. I am going to lower the priority to p3... since this issue is not worth stopping the release of NB 6.8 [which is what p2 'means'] If you can reproduce this issue with nb 6.8 and recent builds of v3, please let me know
lowering to p4