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.
[20040308-trunk] Try do deploy a webmodule with context set to an existing one (not deployed by the IDE - e.g. one of the tomcat's defaults like /, /servlets-examples, /balancer, ...). The deployment fails with an exception in catalina output (attached). The workaround is to manually undeploy the existing webmodule via web manager app. or server instance node. I suspect it's more general problem - I probably applies for all webmodules which are not created (deployed) by the IDE (they do not have an entry in .nbattrs)?!?!
Created attachment 13883 [details] java.lang.IllegalStateException: Context path is already in use
will fix in promo-D
I tried to deploy webmodule outside IDE via tomcat manager and then deploy other webmodule with the same context path in IDE and it failed. So Marek is right. Webmodule deployed outside IDE can't be redeployed inside IDE.
Marku and Libore I have to ask what you expect to happen. I think that showing an error message in this case is actually the right thing to do and the only issue is that it should say "Deployment failed - Context path /balancer is already in use." instead of the current message "FAIL - Encountered exception java.io.Exception:java.lang.IllegalStateException:Context path /balancer is already in use".
Is it possible to add a hint to that message? (advice the user to undeploy the web module) + Have associated Help page which could explain in more details what to do?
I was just little bit confused by the different behaviour of deployment on context of a webmodule deployed from and outside of the IDE. AFAIR for webmodules deployed from the IDE the (re)deployment of another wm on their context is possible. Anyway I agree that more user friedly warning message will solve it. I also like what Karel proposed.
*** Issue 40540 has been marked as a duplicate of this issue. ***
I removed the first part of message (name of exception class) and display only the text as I described above so that it looks like a legal message that informs the user of his error as oposed to IDE failure. We could of course undeploy the previous module silently but what if the user did not want it and typed the same context by mistake? We should not IMO change what tomcat does (and tomcat fails), should we? To enhance the message with more info would be possible but dificult (fragile), as this would depend on the actual text of message printed by Tomcat which can change w/o notice. Also it would need differet handling in japanees etc. If we do that should we also do it for other messages? I do not see an easy way to connect it to help message. There is not way to pass help context from tomcat which knows it to the j2eeserver which displays the dialog - no room for help ctx in the contract. If you think we should enhance the messages file an enhancement.
Verified.