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.
Current state is that the webmodule is redeployed (changes in the context.xml are taken into account only when the path attribute is changed). When user changes the context.xml in a different way e.g. adds a new valve into, the changes are not propagated when the webmodule is executed. The user has to manually undeploy the webmodule and then use the execute action.
j2eeserver takes care of detecting changes and deciding is the module needs to be reloaded, it needs to take server specific config files in consideration in addition to standard DD.
I think that the stop/start/reload/restartserver/... are responsibility of plugin when incrementalDeploy is call. The exact sequences for each situation could be differenet for different platform. If j2eeserver assume a step, it could confuse the complete sequence, so it assume nothing. Plugin has to base on TMID and change descriptors passed in the call to react properly.
Retarget to promo D for further evaluation.
I think, the tremendous effort to fix the issue 39220 was useless when changes in context.xml won't affect the deployment.
This issue seems to me (and all people I have talked about it) worth fixing in promo-B. As Milan pointed out the context.xml editing feature is degradated by the fact that the changes aren't taken into account during webmodule execution. This issue needs at least further evaluation of the team.
OK, so it should be P2 and we will evaluate and resolve this issue now. I added Ludo for comments. I believe we should undeploy or restart or reload (whatever needed) only in the plugin. Change of "root context" is a special case that requires a undeploy (for web modules only). I don't think we want wholesome action like that for any configuration descriptor changes for every platform. It would be costly for large applications. So only restart or reload or whatever minimal should be done at the discretion of the plugins.
I agree this should be fixed on the side of the plugin. In particular, in TomcatIncrementalDeployment.incrementalDeploy(...), this method needs to determine whether to call restart() or reload() on TomcatManagerImpl. In this case, restart() should be called. (That's my guess, at least.) Changing target milestone to TBD, so we don't forget to reevaluate/reconsider this. Assigning to Pavel.
We agreed this is a high priority bug -> raising to P2
the problem is actually in tomcat implementation, sorry for confusion fixed in release36
verified
[nb36-rc3] I have just tried to check the described functionality and I surprisingly realized that it doesn't work. If I try to follow this scenario, the context.xml in $CB/conf/Catalina/host directory is not updated and the changes are not taken into account by the tomcat server. 1) create a webmodule & execute it 2) change $WMHOME/META-INF/context.xml (for example add reloadable="true" attribute to the Context element 3) execute the webmodule Pavel Buzek has already -fixed- this in release36 branch on 04/03/02, see the diff: http://tomcatint.netbeans.org/source/browse/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/ide/TomcatIncrementalDeployment.java.diff?r1=1.3&r2=1.3.2.1 I trully do not understand why I marked the bug as verified even if this do not work - maybe there are some unknown circumstances??? I do not know. I tried to check it also in older builds (20040304, 20040310) and it doesn't work as well. I am really disappointed by this especially because of I pushed this issue to be fixed. Because of my fault the users will have to live with this :-(((. I suggest to waive it now.
I do not see how to fix this so I am asking for a waiver. Tomcat currectly does either start/stop (for web.xml or context.xml) or reload (for classes changed) but for context.xml this is not enough. Maybe we will need to actually undeploy and deploy again. That is not supported by incremental deployment APIs. I will investigate more and try to fix in trunk.
I just noticed this one because it was waived. Stealing from Pavel's waiver text for possible relnote text: Description: When you change the context.xml file and execute the module again, the module is not redeployed with the the changes that were made in context.xml. Workaround: Undeploy the module from Server registry in Runtime tab and then execute the module.
Waiver approved for 3.6.
Looking at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/printer/deployer-howto.html shows me that you should really fix that. Deploying on a running Tomcat server If the host "autoDeploy" property is true, the host will attempt to deploy and update web applications dynamically, as needed. The host will need to have background processing enabled for automatic reloading to work, which is the default. This includes: [...] * Redeployment of the web application if the /WEB-INF/web.xml file is updated. * Redeployment of the web application if the context XML file from which the web application has been deployed is updated. * Redeployment of the web application if a context XML file (with a name corresponding to the context path of the previously deployed application) is added in the $CATALINA_HOME/conf/[enginename]/[hostname]/ folder. Note: Web application reloading can also be configured in the loader, in which case loaded classes will be tracked for changes.
Please check bug #41948. To me it seems that there's something totally wrong with the context file.
*** Issue 41948 has been marked as a duplicate of this issue. ***
I tested with the example that Boris provided in 41948 (thanks!) and the problem is that a change in context.xml required the module to be undeployed and deployed again. One workaround was mentioned here, another workaround is to change context path (I think doing undeploy from Runtime tab is easier though). The solution will require a change in j2eeserver API. I will communicate this with developers of other server plugins and make the change and then get back and fix this issue.
I described your workaround and a possible solution in bug #41948. Tnx.
fixed in trunk
Created attachment 14440 [details] commit log
*** Issue 46141 has been marked as a duplicate of this issue. ***
The problem with not-redeployed context.xml is not fixed in Promo-D. Please reevaluate.
little specification: the webmodule is not redeployed when you change the context.xml metadescriptor file. The change is detected and the wm redeployed only when you modify the contextpath attribute.
Stepane, could you please look at this? Thanks.
Commit log: Checking in TomcatPlanSplitter.java; /cvs/tomcatint/tomcat5/src/org/netbeans/modules/tomcat5/ide/TomcatPlanSplitter.java,v <-- TomcatPlanSplitter.java new revision: 1.4; previous revision: 1.3 done
Build 20040802