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 did the following: 1) Mount an existing application from directory C:/opt/webapps/midnight/mcc-official 2) Exit the IDE 3) Outside of the IDE, moved the directory up to C:/opt/webapps/mcc-official 4) Start the IDE. 5) Unmount the invalid directories. 6) Mount the new file system 7) Execute it. Nothing happens. There is an an error message bug it only shows up in the output window and the IDE log. The problem is that there is already a web module mounted at that path name. NOTE: I have seen this often and I don't think it has anything to do with the fact that the directory became invalid. I'm pretty sure I have seen the same problem when I just mount another directory of the same name.
Created attachment 13168 [details] Stacktrace
BTW, when deployment fails, the update window lives on forever. If you restart the server again succesfully, you still have the old failure message lying around. There is a workaround for this which is why I didn't file it as a P1 - go to the runtime tab and manually undeploy the module.
I think that the right solution would be that if an application with given context path already exists we would display a nice message asking the user to undeploy it or change the context but it should still fail. Correct?
oops, actually to give a nice message we would need to create a table of all possible error messages from tomcat and our descriptions for how to avoid them -- that may be an enhancement but not smtg I can fix now. I will just display the tomcat message and call this fixed.
The old behaviour was to deploy the new application instead of the old one. I think that's OK (especially since we never undeploy anything). BTW, why is the bundled server set up with all the sample apps? If we don't mount them as samples in the explorer also, I don't think there is much point in that.
Sorry, I missed the last comment. I don't think that displaying the message cuts it (at least you have to explain how to undeploy the module, this is even less obvious than before now that the runtime explorer does not show by default). The reason for this is that it's pretty complex to write an application in such a way that it works for any context path (this is because some of the API methods in JSP & Servlet prepend the context path automatically while some don't). So for most developers, working with an arbitrary context path derived from the directory name is not going to work - they will have to set it explicitly. It's fairly reasonable that any one developer will work on more than one web module that is deployed at root. So they would have to go through the process of undeploying any time they switch between those. I recommend that we stick with the old behaviour for now. When we switch to projects, we can deal with undeploying at that point.
BTW: I've seen this problem and I can see in code how it can happen but the described scenario does not reproduce it on my computer. I at least fixed the code to display an error message instead of throwing INFORMATIONAL exception.
Or, would it be useful to display a dialog, warning the user that an application already exists on this context path, and giving the options to either overwrite it or cancel deployment?
Here is an update: the web apps team has discussed this and decided that the behavior we want to achieve it to simply unload the old module and load the new one if they have the same context path. This will be consistent with the behavior in 3.5 and it fits the user model when the server is used by one server, which is typical. This means that this needs to be taken care of in j2eeserver. The j2eeserver needs to do the undeploy/deploy instead of incremental deployment in this case. It probably also means that the context path is NOT a good TMID, since it may not be unique. Perhaps the path of module folder could be used.
Instead of solving this issue only for context change in webapps, I think j2eeserver can define a auto-undeploy mechanism based on a StateType IncrementalDeploy.NEED_UNDEPLOY. Plugin will be in better position to detect undeploy situations in each platform and would generate an event with this StateType to communicate it with tools.
Nam agreed to fix this.
The fix is for in the j2eeserver recoreded deployment info like content directory and context root among other info. On each deployment, current content dir and context root is checked to decide if auto undeploy should be done.