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.
Created attachment 154776 [details] ear's nb-config I have an EAR project (maven), itself packaging an EJB jar and 2 wars (JSF / JAX-RS). CoS is enabled on each project, DoS is disabled. Sometimes, Netbeans starts trying to deploy stuff (EAR or WAR) when I save some file. Some lines that could be relevant in my IDE log: WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [org.glassfish.tools.ide]: Error processing component "Gestemps-ear <ear, webservices, web, ejb> " WARNING [org.glassfish.tools.ide]: Error processing component "Gestemps-ear <ear, webservices, web, ejb> " WARNING [org.openide.filesystems.Ordering]: Not all children in Projects/Actions/ marked with the position attribute: [net.sf.efhnbm.ExploreFromHere.instance], but some are: [org-netbeans-modules-projectimport-eclipse-core-UpdateProjectAction.shadow, org-netbeans-modules-versioning-core-ProjectMenuItem.instance, org-netbeans-modules-vagrant-ui-actions-VagrantAction.shadow] WARNING [org.glassfish.tools.ide]: Error processing component "Gestemps-ear <ear, webservices, web, ejb> " WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [org.glassfish.tools.ide]: Error processing component "Gestemps-ear <ear, webservices, web, ejb> " WARNING [org.glassfish.tools.ide]: Error processing component "Gestemps-ear <ear, webservices, web, ejb> " WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [org.glassfish.tools.ide]: Error processing component "Gestemps-ear <ear, webservices, web, ejb> " WARNING [org.glassfish.tools.ide]: Error processing component "Gestemps-ear <ear, webservices, web, ejb> " WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [glassfish-eecommon]: Deployment plan not supported in GlassfishConfiguration.save() WARNING [org.glassfish.tools.ide]: Error processing component "Gestemps-ear <ear, webservices, web, ejb> " I'll attach a couple of files that could be relevant too.
Created attachment 154777 [details] ear's pom.xml
Created attachment 154778 [details] war's nb-config
Created attachment 154779 [details] war's pom.xml
FYI, this happens seemingly randomly. When it does happen, saving some file triggers redeployment. Restarting Netbeans fixes it for some time.
That's strange. Is it at least semi-reproducible?
Yes: when it does happen, it will stay for some time and each time I save a file, some redeployment occurs (WAR or EAR, it depends). After seeing some other bugzilla issues regarding unnecessary redeployments, and sometimes their stack traces, I'm wondering if it just redeploys if some error occurs. Exception-swallowing catch clause? Guess there is some other root cause which triggers this. Could someone have a look at the code that's involved in deciding if a redeployment is needed after save? Is there something like that there?
Can you also share the IDE log? http://wiki.netbeans.org/FaqLogMessagesFile
Is deploy on save disabled for EAR only or is it disabled for submodules as well?
Can't reproduce this. Could it be caused by separate war/ejb deployment you may have performed?
Try also running the IDE with this additional parameter: -J-Dorg.netbeans.modules.j2ee.deployment.impl.DeployOnSaveManager.level=0 So we may have more accurate information.
*** Bug 244057 has been marked as a duplicate of this bug. ***
Thanks for finding the duplicate. I was quite sure it did exist, but couldn't find it. I'll try with -J-Dorg.netbeans.modules.maven.j2ee.level=0 I don't think there is anything unusual. Maybe edited nb-config files long ago, but I don't think they are unusual right now (see attachments). You'll find some IDE log of when it happens in my first post. I'll attach more complete ones once I'm back coding, normally in a few days. Didn't ever deploy WAR/EJB separately, but Netbeans does try sometimes after I save some file. Deploy on save is deployed in ear / war /ejb. It should be visible in attached nb-config, I guess.
Pleas also add a second parameter: -J-Dorg.netbeans.modules.j2ee.deployment.impl.DeployOnSaveManager.level=0 not just only -J-Dorg.netbeans.modules.maven.j2ee.level=0 Thanks.
Did this happen again recently? Any more details (IDE logs) would help. Thanks.
Created attachment 155444 [details] ide log with flags
Happening again. I attached the logs, with given NB flags. Additional hint: when stopped on breakpoint, unnecessary deployments seem to fail immediately.
(In reply to ymajoros from comment #16) > Happening again. I attached the logs, with given NB flags. > > Additional hint: when stopped on breakpoint, unnecessary deployments seem to > fail immediately. Do you remember some basic steps you did? Such as Run, Run, change web.xml, Debug... I'm investigating the log and the code.
(In reply to ymajoros from comment #16) > Happening again. I attached the logs, with given NB flags. > > Additional hint: when stopped on breakpoint, unnecessary deployments seem to > fail immediately. Is it actually deploying anything? Or you just assume that based on the status bar? Does it show "Deploying" or "Updating". I don't see any successfull DoS event in the fresh IDE log.
Ok I found at least one possible case when this could happen and fixed it. It would be great if you could test the dev build once integration message appears here. web-main f9a8e2c68bb5. The reproducible case was: 1) Run app with DoS off (DoS state MODULE_NOT_DEPLOYED) 2) Debug it 3) App stopped at breakpoint 4) Change source (DoS state SERVER_STATE_UNSUPPORTED) 5) Continue with the app (release breakpoint, detach JPDA) 6) Change source (DoS state MODULE_UPDATED) The IDE is now in the state where it do DoS. Now with the fix the DoS in step 6) is still MODULE_NOT_DEPLOYED.
Great work :-) This had been hiding for years. Indeed, your explanation seems to make sense, and the trigger could be exactly what I'm doing. I'll check the latest build as soon as it's available. Thanks!
Should I add that I almost always run in debug mode? ;-)
Integrated into 'main-silver', will be available in build *201508200002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/f9a8e2c68bb5 User: Petr Hejl <phejl@netbeans.org> Log: #253630 - (yet) unneccessary deployments while deploy on save is off
New build is downloading. I can already confirm that I can reproduce the problem at will too with the steps you gave. Anyway, I'm wondering: why do we ever arrive at "4) Change source (DoS state SERVER_STATE_UNSUPPORTED)"? Shouldn't there be a new state to support debugging?
(In reply to ymajoros from comment #23) > New build is downloading. > > I can already confirm that I can reproduce the problem at will too with the > steps you gave. > > Anyway, I'm wondering: why do we ever arrive at "4) Change source (DoS state > SERVER_STATE_UNSUPPORTED)"? Shouldn't there be a new state to support > debugging? Well it is just an internal state not perfectly accurate. Debugging is supported in general. Same for MODULE_NOT_DEPLOYED which does not necessarily mean the module is not deployed, just for example not being DoS enabled etc.
Just checked the new version, and it's solved! Thanks :-)