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.
dev build 200811011401 Opening or closing files sometimes triggers a webapp redeploy even though the file contents was not changed at all. Perhaps Netbeans is updating the file timestamp when it shouldn't? This is a problem because Tomcat and Glassfish run out of PermGen after 10 or so redeploys. Some of the bugs come from the container, others from the application (for example, Google Guice is never unloaded properly). In any case, fixing these unnecessary redeploys should improve the situation until the underlying bugs are fixed.
Reassigning to web.
I agree that this should be dealt with. Every time this feature kicks in it logs me out. I tried telling GlassFish V3 to "Preserve Sessions Across Redeployment" but that only seems to work some of the time. I would simply just turn off "deploy on save" but then I would end up having to stop and start my profiling or debugging session. Please fix
I can confirm this with GlassFish V2. Just closing a file with [Ctrl+F4] or [Ctrl+W] in the editor without saving initiates a re-deploy. Equally important is the fact that IDE re-deploys even if a Java file fails to compile. Sure, the source file is saved, and the feature "Deploy on Save" is used as advertised, but it is counter-productive in this case.
I believe this is a duplicate of issue 166188, which was fixed in NetBeans 6.7.
I also think this is fixed,,, Thanks! *** This issue has been marked as a duplicate of 166188 ***
Hi, For me, this is not solved in 6.7 final (Java Enterprise app with ejb and web modules). I get rapid fire deployments on closing files in the editor. How can this be a duplicate of issue 166188 when 166188 involves GF v3 Prelude while this involves GF v2? I am using GF V2. If GF V3 is a full blown replacement of GF V2 then of course this makes sense, but can I switch from V2 to V3 now in a production environment? For an unknown reason, GF V3 is not in the set of servers in my Netbeans 6.7 installation. It was available in 6.5 but I did not use it. Best regards and many thanks Bernard
It is duplicate because redeployment is not server specific. Reassigning.
I think there may be some confusion. If it is a duplicate of another issue (I am not saying it is not) then the other issue must not be closed (it is effectively closed by being marked as being fixed by 161367) because I can still reproduce this problem. I think it would pay to clean up these dependencies a bit.
Bernard, you are right this issue should be left open (as it currently is) and investigated. phejl was trying to say that the target server does not matter and this is not server-specific. It looks like some situations (represented by issue 166188) are fixed, while other situations (represented by this issue) are not. It would be great if you (or anyone else) can find steps to reproduce starting from a clean IDE (empty userdir), as we currently can not reproduce this. Thanks.
Also, please include the platform/version info from the NetBeans About box. Thanks.
How to reproduce this: - Close netbeans. - Rename userdir. - Start netbeans with missing userdir - Menu|File|New Project|Samples|Java EE|Servlet Stateless - Run the project by right clicking on the ServletStateless Enterprise Application Project icon, select Run. - Edit the file Servlet2Stateless.java, make a small change to the HTML text. - Save the file Servlet2Stateless.java. Auto deploy deploys the change. - Wait a few seconds - Close the file Servlet2Stateless.java. Auto deploy deploys the change. This is unnecessary. 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
reassigning by request to editor-P&I
I can reproduce this in my dev build.
http://hg.netbeans.org/jet-main/rev/67e59521c99d
I am sorry, but we can't do that for NB 6.7.1 ... let's schedule that for next patch
Integrated into 'main-golden', will be available in build *200907150249* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/67e59521c99d User: Vita Stejskal <vstejskal@netbeans.org> Log: #152222: be more careful about reindexing edited files when they are closed
As a user, I am very impressed by the professionalism and the culture of the NetBeans team. It is a pleasure to work with you.
Thanks, Bernard. Can you please confirm that the problem is fixed for you in the latest dev builds? Thanks.
Works for me in Build 200907171401. Thanks.
*** Issue 168914 has been marked as a duplicate of this issue. ***
Unnecessary re-deployment still occurs in 6.8M2. Please check this new test case. - Menu|File|New Project|Samples|Java Web|Servlet Stateless (Java EE 6) - Choose server GlassFish V3 - Register server C:\Program Files\glassfish-v3-b66 - Register local domain domain1 - Deploy on save is checked. - Run project. - Edit Servlet2Stateless.java - Add a line line without saving - Open StatelessSessionBean.java without modifying it. - Automatic deployment occurs This may or may not happen due to "1 files(s) automatically backed up." Unnecessary deployment is apparently triggered when switching in the editor from the changed file to another.
Thanks, I'll investigate. Btw. have you tried 6.8beta, but I guess it's probably broken in 6.8beta as well.
It is really easy to reproduce this. Please just follow the steps.
Ok, I can reproduce the behavior. The question is whether this is actually wrong behavior or not. I understand deploying the file after adding an empty line looks silly. On the other side if you really change some code (eg. add a new method) the file is going to be reindexed, which will make the new stuff available to other classes, which you can then modify (eg. call the new method) and save and deploy. With the current behavior both your classes are deployed and in sync on the server. Anyway, I changed the behavior not to deploy classes that are reindexed just because of their editor modifications. However, this may affect other features like compile on save, etc. Should there be a need to rollback this change in the future, I will close this as WONTFIX. http://hg.netbeans.org/jet-main/rev/4af3c8399285
Thanks for the fix, Vito. Though regarding: > The question is whether this is actually wrong behavior or not. Clearly the users' expectation is that the app should not redeployed if I don't save it, and the behavior before your fix was seen as unintuitive. I listen to what actual users tell me.
Integrated into 'main-golden', will be available in build *200910280201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/4af3c8399285 User: Vita Stejskal <vstejskal@netbeans.org> Log: #152222: prevent deploying classes that are reindexed due to their modification in the editor
Integrated into 'main-golden', will be available in build *201102160501* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/90897880fe1e User: Jan Lahoda <jlahoda@netbeans.org> Log: #187514: not re-deploying application when a resource is changed, similarly to #152222 for Java.
I just wanted to file a new Bug about this issue and then found this one. So, the Bug is still present in NB 7.2: Product Version: NetBeans IDE 7.2 (Build 201207171143) Java: 1.7.0_03; Java HotSpot(TM) 64-Bit Server VM 22.1-b02 System: Windows 7 version 6.1 running on amd64; Cp1252; de_DE (nb) User directory: C:\Users\BJudas\AppData\Roaming\NetBeans\7.2 Cache directory: C:\Users\BJudas\AppData\Local\NetBeans\Cache\7.2 Working on various JavaEE-Applications sometimes leads to the described behaviour: Simply jumping between tabs of open files (without any change or save) leads to a redeployment of the application. Sometimes, even when I stop the Glassfish-Server, and it's completely shut down, that issue leads to Glassfish being started again, just to do the redeployment - plain annoying. Turning "Compile on Save" of (i.e. setting it to "Never" in the projects properties) seems to help out, but unfortunately this also means that you have to manually build and redeploy the application everytime you want to run another debug-cycle. First of all, I thought using Git as VCS was the reason for this behaviour: maybe git would 'watch' the files and touches them when being viewed. But on the other hand, the files don't seem to be touched at all when I just view them in the IDE, advanced file properties information don't show anything suspicious either. I think (but I am not sure) the problem started to occur just a short time after I switched my JavaEE-Projects to Git, but I cannot think of any way how Git could cause such behaviour. I already tried: - Watch the IDE-Log: Doesn't show anything suspicious, just that Netbeans is redeploying to my local Glassfish instance (GF 3.1.2, that is) but not *why* it thinks a redeployment is neccessary -- can somebody tell me where the IDE-Logger is configured? I'd like to make it *really* verbose, maybe this could give some information. - Clean the IDE-Cache (C:\Users\BJudas\AppData\Local\NetBeans\Cache\7.2\index, that is) - no help. - Turn "Compile on Save" for the projects off - this did help, but (of course) is not an option that's really desired. I'd hope to get some informations, especially about the Log-Configuration, maybe I can find out something for myself. Thanks in advance & best regards Benjamin
Just filed my comment and got a few more informations: these unwanted redeployments immediately occur after messages like these appear in the IDE-Log, a pack of about 20 - 30 lines similar to this: WARNING [org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater]: D:\NetBeansProjects\GeneratorNG\GeneratorNG-ejb\src\main\java\com\zellner\generator\mesonic\rawdata\WinlineRawData.java@ef40aae6:3b79eade does not lie under D:\NetBeansProjects\GeneratorComponentsNG\src\main\java@d17f20cc:24000778, not indexing it Could it probably related? I read in bug 166188 something similar. But that bug is fixed.
This bug report is quite old, and if there are still problems in this area, then they may have a different root cause than the original report. So could I please ask you to file this as a separate issue (against the javaee component)? Let's not mix the new findings with the original problem, because the original problem may not be relevant any more to the current issues. Also, could you please try if this is still a problem in the latest NetBeans 7.3 Release Candidate 2? This RC is very close to the final build, which will be out in the next few days. Also, is your project Ant-based or Maven-based? If you file a separate new report, feel free to put me on cc so we remember to investigate fast. Thanks.
(In reply to comment #30) > This bug report is quite old, and if there are still problems in this area, > then they may have a different root cause than the original report. So could I > please ask you to file this as a separate issue (against the javaee component)? > Let's not mix the new findings with the original problem, because the original > problem may not be relevant any more to the current issues. > > Also, could you please try if this is still a problem in the latest NetBeans > 7.3 Release Candidate 2? This RC is very close to the final build, which will > be out in the next few days. Also, is your project Ant-based or Maven-based? > > If you file a separate new report, feel free to put me on cc so we remember to > investigate fast. Thanks. Hello Petr, thank you for your quick reply. In the mean time things over here have changed. I had postponed the recent JDK-Updates on my workstation since I simply didn't have the time and notion to run the updates (yes, shame on me, I know). Now as a last try I actually did upgrade to 7u15 this morning since I remembered from recent Netbeans troubles unter MacOS X, that a 'wrong' JDK/JRE might cause strange behaviour. For now it seems that my problem is solved; no more silly, unwanted redeployments. So I am going to do as follows: I'll have an eye on the whole situation and see, if it really works and the problem is solved. If not, I'll follow your suggestions this weekend. Again, thanks for your quick reply and sorry for the bothering... running all recent upgrades should've come to my mind much earlier :-)
I'm experiencing the same problem with Netbeans 8.0.2 and JSF projects. My operating system is Linux (Ubuntu).
.. and my JDK is the newest version: 1.7.0_75-b13
This is still happening. To reproduce. Create a web app on GlassFish with web pages and source packages 1. Click between web pages - no redeploy (Expected behaviour) 2. Click between Source package java files - redeploys (reported incorrect behaviour) Product Version: NetBeans IDE 8.0.2 (Build 201411181905) Updates: NetBeans IDE is updated to version NetBeans 8.0.2 Patch 2 Java: 1.8.0_40; Java HotSpot(TM) 64-Bit Server VM 25.40-b25 Runtime: Java(TM) SE Runtime Environment 1.8.0_40-b25 System: Linux version 3.19.0-23-generic running on amd64; UTF-8; en_US (nb)
XRayA4T, Please open a new/separate bug report as this fix has already shipped in a public release.
(In reply to _ gtzabari from comment #35) > XRayA4T, > > Please open a new/separate bug report as this fix has already shipped in a > public release. Done. https://netbeans.org/bugzilla/show_bug.cgi?id=268210