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.
[I filed this for 3.4 but it's been the behaviour of the IDE for as long as this functionality has been present] Whenever a user wants to run a web module, we deploy it to the server. We never explicitly remove the web modules they worked on before, so this will only happen implicitly if the new web module was specified at the same context root as an old one. This can cause confusing behaviour to users (because start up messages from the old modules are printed to the log files), see nbusers thread in URL. Worse, it slows down the startup time on the server. When we switch to projects, we should take the opportunity to fix this behaviour.
Strongly disagree. Removing all applications when deploying the other one is data loss.
I don't think it makes sense to leave the modules running for the following reasons. 1) The analogy of this in the Java world is that if you execute one project, all other Java projects that you have been working on get run also. This is not what developers expect: they expect exactly the code that they have indicated should be run to be run. 2) Leaving old modules running is a performance problem. It takes the server longer and longer to start the more modules are deployed. This would be particularly noticeable if the target server is an app server rather than a relatively lightweight web server as in this case. 3) Leaving old modules running means that error messages on startup from old modules are shown, which can be very confusing in case the modules contains JSPs or Java classes of the same names. See thread on nbusers. Note that this will get worse from J2EE 1.4 onwards, where the server has to parse the deployment descriptors using an XML schema instead of a DTD, which is intrinsically slower. The only way to undeploy modules that we currently provide is through the server integration interface. User feedback on nbusers indicates quite clearly that many of our users are not aware of this UI. 4) The only benefit I can see of doing things this way is that it provides a mechanism for users to deploy multiple web modules at the same time. But this is a mechanism over which users have very poor control, and receive little feedback. If the intention is to support simultaneous deployment of multiple web modules, then there should be a proper UI for this.
The weak part of this analogy is difference between deployment and execution. The result of deployment is application running on some server and lifecycle of this application is controlled by this server (using remote tools is of course possible). The goal is not to restart server every time when project is run (executed, deployed) so 2) is lower priority. ad 3): we can think about solution when apps (web modules) deployed from the IDE are not persisted across server session though this can be difficult. I mean that this is answer to original problem. Definitely we should not deploy one app to more contexts like we did (do?) if context root is changed. The UI for undeployment (i'd say whole server registry) is hard to find and smarter integration with the rest is appreciated. Currently I don't know how to improve it. 4) At least we will require 'manager' app. 'Admin' app is very usefull too I think and keeping ROOT context application seems to be good and also give us possibility to add some usefull informantion. Of course the default config needs to start correctly. Simultaneous deployment of web apps is low priority since it is not usual IMO and I am not sure how much to support it.
Just a quick addition - the main use case scenario for simultaneous deployment is in the domain of portal apps. Some time in the future maybe we should consider a portlet project.
This could be done each time a web-module is 'deploy'ed (right-click pop-up menu cmd), it should be redeployed entirely, ie the its context deleted, and re-deployed.
One advantage of the 4.0 user model is that we have a good definition of what "modules that are no longer worked on" means. I think that if the user closes the project which provides the web module it would be the right time to undeploy it. Maybe after first asking the user (and letting them to check the [x] Don't bother me with this question again).
One other option would be to ask this question in the execution profile before the module is ever deployed (not to have to anoy people by displaying modal dialog). I will consider this a nice-to-have for 4.0.
BTW: we need to investigate how the deployment process works. I mean whether webapps deployed through manager persist across sessions or not (or if it can be customized).
not planned for specific release
I filed issue 83122 without realizing this was here. I posted some code there that goes a ways towards doing what I consider to be the proper behavior, which is: 1. "Clean" should undeploy the project's context 2. "Deploy" should always force a redeploy.
This old bug may not be relevant anymore. If you can still reproduce it in 8.2 development builds please reopen this issue. Thanks for your cooperation, NetBeans IDE 8.2 Release Boss