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.
See http://stackoverflow.com/questions/5965798/netbeans-deployment-fails-after-class-rename for details. I was able to replicate the problem and have given a work-around in the question. In my case, I created a JSF CRUD app based on the 'sample' dataset. I deployed it and saw that it executed correctly. Then, I renames DiscountCodeController to discountCodeController... Once I did that, I could not get the app to deploy... until I shutdown everything and deleted the NetBeans cache... I am going to mark this as P2, since the work-around is pretty drastic (from a user experience perspective)
Does it help if you turn off Deploy on Save? Looks like a problem in the deployment infrastructure or the Java infrastructure.
It appears there are three or four distinct problems: 1. when only the case differs, the FileRenameEvent that arrives to FileChangeListener.fileRenamed returns the original name including extension from getName() and the new name including extension from getExt(). That is obviously not correct, and appears to be causing ugly problems to the indexing. 2. There are actually two different events arriving to RepositoryUpdater in this case: update of the original file and rename. This gets expanded to update-delete-update, but due to performance optimizations, this gets collapsed to update-delete, which ultimately leads to incorrect caches in this case (on case-sensitive filesystems, or for other kinds of updates, the result may still be broken, but with much less severe consequences). The simplest solution is probably to put deletes before any other kinds of jobs. 3. FileUtil.normalizeFile keeps the normalization map even for deleted files, so that: File f = new File("C:\A"); //that exists as C:\a FileUtil.normalizeFile(f); //== C:\a f.delete(); FileUtil.normalizeFile(f); //== C:\a !!!!! - should be C:\A f.createNewFile(); FileUtil.normalizeFile(f); //== C:\a again This leads to .class file created with incorrect name. I believe that the FileUtil.normalizeFile should: -not change the input casing for non-existing files -return the exact casing as is on disk for existing files 4. BuildArtifactsMapperImpl is using FileUtil.normalizeFile which in combination with 3 leads to incorrect file name of the newly created (class) file. I currently do not see why normalization would be mandatory in this case, so removing that would both workaround 3 and improve performance. Fixing either 1, 2, 3 or 1, 2, 4 should fix the problem (I tested with 1, 2, 4). We (me or tzezula) are going to fix 2. I will try to remove the normalization (4), but I would like to ask QA to test deploy/compile on save after this change. Jarda, could you please fix 1? Should I file bug for it? I will file a separate bug with a unit test for 3. For 7.0.1, I propose to propagate fixes for 1., 2. and 4. (if it proves to be safe).
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/ad241dfb5678 User: Jan Lahoda <jlahoda@netbeans.org> Log: #198565: file normalization after resolving relative file is probably not needed in BuildArtifactsMapperImpl, and causes problems due to #199471.
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/a049b6b8a833 User: Jan Lahoda <jlahoda@netbeans.org> Log: #198565: preventing forerun of DeleteWork by FileListWork through absorb.
I have tested daily build 201106260600, and it seems OK. Steps to reproduce: -create a web project whose server is Glassfish -create a servlet -deploy ("Run") the project -do a class-sensitive rename of the servlet, save, and wait until the app is redeployed -watch the "Glassfish Server 3.x" tab in the output window: it should not list any error Stepan and/or Vince, could you please verify? Tomas, could you please review the two above patches (ad241dfb5678, a049b6b8a833)? Thanks.
Created attachment 109136 [details] glassfish log Product Version: NetBeans IDE Dev (Build 201106260600) Java: 1.7.0; Java HotSpot(TM) Client VM 21.0-b16 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) GlassFish Version: GlassFish Server Open Source Edition 3.1.1-b09 (build 9) With "Deploy On Save" turned off everything seems to be ok now. With "Deploy On Save" turned on, the server keeps running and application is successfully deployed and works after case-sensitive rename, but there are still few exceptions (see log). Please evaluate.
Reopening for evaluation...
Thanks for the test. Petr H., could you please take a look at the exception in the log? I have no idea what that is, but I found bug #158704, which appears to have a similar stack trace. Might it be related? Thanks.
The exception from log does not seem to be related to the issue reported originally. It looks like duplicate of 158704.
Seems good to me.
Merged to release701: http://hg.netbeans.org/releases/rev/3775016f7d8a http://hg.netbeans.org/releases/rev/fd77b3b00def Fix for 199616 merged as: http://hg.netbeans.org/releases/rev/bb13bb8e2b81
Integrated into 'releases' Changeset: http://hg.netbeans.org/releases/rev/3775016f7d8a User: Jan Lahoda <jlahoda@netbeans.org> Log: #198565: file normalization after resolving relative file is probably not needed in BuildArtifactsMapperImpl, and causes problems due to #199471.
verified in 7.0.1 build 201107160900
*** Bug 202723 has been marked as a duplicate of this bug. ***
*** Bug 199920 has been marked as a duplicate of this bug. ***