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.

Bug 198565 - Compiler cache interferes with class renames on Windows
Summary: Compiler cache interferes with class renames on Windows
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Infrastructure (show other bugs)
Version: 7.0.1
Hardware: PC Windows 7
: P2 normal (vote)
Assignee: Jan Lahoda
: 199920 202723 (view as bug list)
Depends on: 199471 199616
  Show dependency tree
Reported: 2011-05-12 21:56 UTC by Vince Kraemer
Modified: 2011-10-25 12:51 UTC (History)
10 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

glassfish log (35.62 KB, text/plain)
2011-06-27 17:23 UTC, Stepan Zebra

Note You need to log in before you can comment on or make changes to this bug.
Description Vince Kraemer 2011-05-12 21:56:25 UTC
See 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)
Comment 1 Petr Jiricka 2011-05-19 12:07:52 UTC
Does it help if you turn off Deploy on Save? Looks like a problem in the deployment infrastructure or the Java infrastructure.
Comment 2 Jan Lahoda 2011-06-16 15:03:10 UTC
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
FileUtil.normalizeFile(f); //== C:\a !!!!! - should be C:\A
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).
Comment 3 Quality Engineering 2011-06-18 15:11:32 UTC
Integrated into 'main-golden'
User: Jan Lahoda <>
Log: #198565: file normalization after resolving relative file is probably not needed in BuildArtifactsMapperImpl, and causes problems due to #199471.
Comment 4 Quality Engineering 2011-06-25 14:08:26 UTC
Integrated into 'main-golden'
User: Jan Lahoda <>
Log: #198565: preventing forerun of DeleteWork by FileListWork through absorb.
Comment 5 Jan Lahoda 2011-06-27 09:34:28 UTC
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.
Comment 6 Stepan Zebra 2011-06-27 17:23:39 UTC
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.
Comment 7 Stepan Zebra 2011-06-27 17:25:02 UTC
Reopening for evaluation...
Comment 8 Jan Lahoda 2011-06-27 17:31:35 UTC
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.
Comment 9 Petr Hejl 2011-06-28 15:39:08 UTC
The exception from log does not seem to be related to the issue reported originally. It looks like duplicate of 158704.
Comment 10 Tomas Zezula 2011-06-30 07:15:22 UTC
Seems good to me.
Comment 12 Quality Engineering 2011-07-06 00:01:44 UTC
Integrated into 'releases'
User: Jan Lahoda <>
Log: #198565: file normalization after resolving relative file is probably not needed in BuildArtifactsMapperImpl, and causes problems due to #199471.
Comment 13 Stepan Zebra 2011-07-19 12:38:51 UTC
verified in 7.0.1 build 201107160900
Comment 14 Jan Lahoda 2011-10-20 08:00:46 UTC
*** Bug 202723 has been marked as a duplicate of this bug. ***
Comment 15 Jan Becicka 2011-10-25 12:51:28 UTC
*** Bug 199920 has been marked as a duplicate of this bug. ***