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.
The current strategy is to redeploy or restart the web module only if some of the "important" files change (classes, web.xml, etc.). The list of important files is checked in j2eeserver and changes are reported to plugins via ModuleChangeDescriptor. J2ee modules are asked about files that cannot be detected by j2eeserver (ejbs). This is a big design flaw that causes problems with files that also require reload but are not listed in j2eeserver module, e.g. struts.xml, properties files for classes (that require the classes to be reloaded when changed), etc. Some of these examples can be fixed but in general the j2eeserver cannot possibly envision all the cases that may require reload for every type of module. One solution could be to take an opposite approach: report the files that do not require redeployment and in other cases redeploy the module. Another possible solution would be to let web module construct the list of changes. I addition we may consider making it easier to force redeployment or restart of module from popup menu, w/o having to go to Runtime tab.
The "force deployment" is confusing to users. They don't know what it means and often use it exclusively to be "safe" and as a result perception of performance suffers. Therefore, it shouldn't be as prominent as 'faster' ways of executing, and we should try to cover all the cases we can conceive to detect when we have to force deployment.
This is an approach that will simply not work. We can cover a "hello world" type of applications, but we cannot concievably cover all cases, especially not all extension not covered by the J2EE spec (such as JSF, Struts, etc.). If you think you can come up with a list of files and let me find a counter example :-) In the mean time, there is a particular problem with several types of files that should be covered until we come with a broder fix. I propose to add .properties files in WEB-INF\classes and .tld files and .xml files in WEB-INF.
It looks like P2 for me.
Pavel did fix yesterday and he committed the fix into main trunk as well. There is Pavel's fix: http://j2eeserver.netbeans.org/source/browse/j2eeserver/src/org/netbeans/modules/j2ee/deployment/impl/ServerFileDistributor.java.diff?r1=1.10&r2=1.11
George, the issue came up because I have been attempting to update the Midnight Cookies tutorial application, which is not particularly complex, but which does represent a more realistic development scenario than I fear that the IDE has been tested with so far. It is not transparent to the user which files the "execute" action fails to recognize as requiring a reload of the application, and users might waste a lot of time believing that they have not fixed a bug when in fact they have. If the restart action is prominent, that signals that it is known that the IDE might not succeed in restarting the application always and that is helpful to the user. Also, the failure to provide such an action suggests that the design failed to take into account the many legitimate (and frequent!) cases where a user must restart the server, for example because they have to clear the session or sign-on.
I agree with Ana that an "Clean Execute" (or whatever more descriptive name) next to "Execute" would be very helpful for developer and I don't think they would be confused if we do a good HI job. The clean-execute action would force undeploy/deploy steps. I am not sure we should add action with force restart server. I wonder if undeploy/deploy would already cover the "clear session or sign-on" cases that Ana cited. If we do, it would be separate action with name like 'Clean Execute with Server Restart'.
Reviewed by QE. The fix is fine. I was testing it today on the continuous Build 20040312-1224.
I do not think there is direct dependency on #40943. Solving #40943 would only solve part of this problem (the WEB-INF/classes) and not the other files (such as additional deployment descriptors). It would also only work for bundled tomcat, not for servers added manually.
I have integrated the hotfix into release36 branch. I am downgrading the issue to P3 and keeping it open for promo-D. And I appologize for the confusion that may be created by mixing the hotfix with the more general issue into one report.
The case can also apply to *.JSP files in the web app. It was assumed so far that JSP changes would be notified by the web server or app server, and recompiled and reloaded automatically. While this is happening, some JSF apps still need a redeploy even if only a JSP file changed. For example, a change in the button name of a JSF button in a JSP, is not reflected in the Web UI at page reload, since the JSF backing Java file still has a copy of the 'old' Button name. Don't know yet if this is a JSF 1.0 bug or not. See the Sun bugtraq number 5004229.
We can do a lot better by treating all changes in web-inf/lib and web-inf/classes as classes-changed, as pretty much anything in these directories is loaded by the classloader, and so requires a classloader refresh if there are any changes. We could also assume that "other" files in web-inf also need classloader refresh - this will possibly result in too many classloader refreshes, but only in very limited cases. Finally, in the jsp case, I think this is a server bug, and we should address it at such. In any event a 'clean' or undeploy would catch this, without added a Force Redploy action.
ignoring known 'possible server' bugs is not what customers will appreciate. The jsp case is there for real, for some period of time (months/years?), we know it today, and we should deal with it now. Customers will see (A+B), and don't care is the bug is in A or B. If the clean 'action' can be streamlined with a "re-deploy", in One popup action, called "force redeploy" or whatever name HIE can come with, then we should expose it to improve overall usability of the product. Or: Plugins for Servers that have known bugs, need to be able to provide what customers expect: a working product. So, it obvious that treating the issue as a server issue, means that NetBeans j2eeserver module has to provide APIs to server plugins to detect which web app files have changed (including hidden files like for ex .nbattr), so that server plugins can deal with such situation.
I agree with Ludo that we shouldn't hide behind server bugs. Another solution could be that the "Run" action *always* redeploys (undeploys and deploys) the module. This addresses Ana's and Ludo's case. If the user wants to make simple changes in JSPs without redeploying the whole application, they should be able to accomplish this using the "Save in editor + Refresh in browser" sequence.
Actually, I also want to ensure that we make it easy for the user to incorporate changes to the server that are relevant to the user's application. For example deploying libraries to the server; changing the authentication configuration of the server; handling single sign-on; configuring DB access at the server level ... An important use case to consider is a portlet application, where the user typically deploys multiple actions together; and these interact at the level of the server. I filed this bug based on having used the IDE to develop for the preceding week. While it's good if the execute action handles a lot of common cases, it is unreasonable to expect that it will second-guess the developer for every possible case; and given that you usually meet the corner cases for the server at some point (I reported a lot of bugs against Tomcat while doing this!) the user needs to be able to force a reload and even restart the server regularly, to ensure that the problem is not with the server. In an ideal world this might not be the case, but we have to be realistic about it. IMO, the actions we present as part of the UI have to be based on our experiences of using the IDE to develop these applications, and we have to be realistic about the shortcomings of all the pieces involved and their ability to clear their settings... That should be the single most important factor that determines the UI & API design. I am particularly concerned about the portlet case where we don't have any user feedback at this point.
BTW: calling the action "Execute" is not intuitive. see http://www.netbeans.org/servlets/ReadMsg?msgId=721318&listName=nbusers I am adding a link here since this should be considered when redesigning the deployment related actions for the next release.
So what is the current behavior and what else needs to change in this area? I'd like to know how it currently works in NetBeans 4.0 dev builds.
I think it was fixed -- see issue #43394.