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 found that a major problem with JDeveloper (and a major reason why I switched back to NetBeans) was it's ineptness when it comes to efficient development. It was painful to have to stop and restart the "OC4J" (servlet) container for every change I made in a bean or class. Turned out that there was a nasty bug preventing this auto class reloading.. (Of course, Oracle 'stole' orions app server, where the bug actually exists) .. hence the swtich. Netbeans integrated Tomcat supports auto class reloading, yet it's not enabled by default with the Netbeans install. (As of 20040310) I have found that enabling auto class reloading is an extremely useful feature! For instance, I have a rather large webapp that has many stateful objects. Fortunately, Tomcat serializes the session during shutdown / restart, but it is still inconvenient to have to restart Tomcat on every class change. By adding the element: <DefaultContext reloadable="true" /> immediately before the context definitions in server.xml, I am now able to recompile a supporting bean / class and have Tomcat detect the change and auto reload the new class. This has saved enormous time dealing with Struts (as ALL business logic is in the supporting Struts beans or classes) I feel that this is a defect, since a development servlet container (in my experience) should have this enabled by default. I'm quite surprised that it's not, as it's not immediately obvious how to enable this feature. I think that if this is on by default, the more inexperienced users will find it very pleasent to be able to make a change, and have it appear with only a recompile. I will gladly help if I can! Cheers! -Sean
This is a good suggestion but unfortunately it is too late to change this for 3.6. We are in the high resistence mode when we only fix show stopper bugs and this is more of an enhancement. Should be considered for promo-D.
Is this in the horizon for 4.0?? :0)
Yes, I think it will get in 4.0.
We already support this feature by calling Tomcat Manager's "reload" command in the "Run File/Project" action, if any class change has been detected. This seems to be more convenient than setting the "reloadable" attribute to "true", in which case class reloading might become an unwanted side-effect of the "Build Project/Compile File" action. You don't always want web application to reload when running build.
This is interesting. A couple of things: 1) Reading the docs for Tomcat 5, it seems that one would want to use the contex.xml file that resides in the META-INF folder for configuring the context. This works well for my pooled datasources. However, the reloadable="true" does not seem to work. 2) It's a royal pain to have to "stop" "debug" 'close browser window that pops up' 're-establish my session'. This reminds me of the days when I was forced to use JDeveloper with their OC4J container. (Pure junk) I reaaaaaly wish that the auto class reloading feature either worked, or could be enabled. At the very least, add an action (where the run, debug, stop, start) that would be a one-click 'reload context'. All I know is that as cool as NB4 is, I feel my productivity has been seriously stunted because of the inability of Tomcat to detect even something as trivial as a newly added GIF file. Thanks for taking the time on this. -Sean
DoS solved this (and reloadable="true" is enabled now for any new project anyway).