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 have a bug in tomcat (#40526) that I think I cannot fix with the current j2eeserver API. The problem is that a change in tomcat's context.xml requires the web module to be undeployed and deployed again. What I currently do in tomcat is either start/stop (call manager/start?path=/x and manager/stop?path=/x) for changed descriptor and/or context.xml or just reload (manager/reload?path=/x) for changed classes. The problem is that a change in context.xml actually requires to call manager/undeploy?path=/x and manager/deploy?path=/x&war=/full_path_to_war (or perhaps manager/deploy?update=true&path=/x&war=/full_path_to_war). The method public abstract ProgressObject incrementalDeploy(TargetModuleID module, AppChangeDescriptor changes); does not have enough parameters for allow call to deploy (I need config file and document base). We can add another variant of this method public ProgressObject incrementalDeploy(TargetModuleID module, AppChangeDescriptor changes, DeploymentConfiguration configuration, File dir); that will be called from j2eeserver and make it delegate to the existing method. This will keep backward compatibility and S1AS does not need to change anything.
Another approach with much less coding for plugin is to have something like: IncrementalDeployment.getFilesRequiringRedeploy(ModuleType type). j2eeserver incremental deploy code needs to check the list for changes before start copying just like it currently check for changes in content directory path or context root.
I would vote against this change. The object that implements IncrementalDeployment has already gotten the DeploymentConfiguration object as an argument to a required preceeding call. The object that implements IncrementalDeployment has already computed the File object that would be used as the proposed fourth argument. I don't think the j2eeserver code should "remember" where a module is deployed. That is what this API modification would imply.
To Vince: incremental deployment can be called between 2 IDE sessions. What you are proposing would require the plugin to "remember" (i.e. persist) the file somehow which is not acceptable. Also, j2eeserver does not need to remeber the file because it gets it every time it call deployment. The code change in j2eeserver will be trivial. To Nam: Again, the change in existing plugins that do not need this is zero, because the new method would not be abstract and would delegate to the existing method (so this is a backward compatible change). Otherwise what you are proposing could work, but IMO it is against the strategy we use in incremental deployment which that j2eeserver tells plugins what has changed and plugins take an appropriate action based on that. FYI: I am looking into another option which is to include the document base folder into Tomcat's implementation of TargetModuleID (suggested by George). If that works this API change will not be needed at all.
OK, the proposal from George worked = I was able to fix the issue #40526 in tomcat only.