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.
Although the WEBrick server shows up in the runtime tab, there is no available action to start or stop it. The only way to shut it down seems to be shutting down NetBeans itself ... and you have to remember to click the checkbox to go ahead and kill this external process as well -- otherwise, you will leave behind an orphan. There should be ways to manage this server on the Runtime tab.
In my experience, even shutting down NetBeans doesn't terminate the process (even though it says it will).
This should be fixed now; there is a Stop button right in the webrick window, and process killing should be working. (Please let me know if it does not; it's definitely fixed on Unix but I can't verify on Windows, and since the changes involved the startup scripts (adding exec to the jruby unix script), I wonder whether similar changes are necessary for the Windows jruby.bat file.
Tor, the stop button isn't stopping WEBrick on Windows, although it thinks it does. So trying a restart just causes a port conflict error. /Brian
I've just checked in a fix which I hope will take care of this. The fix is to bypass the JRuby launcher scripts completely (avoiding the fork/exec issue with .bat files that were fixed by doing an exec in the Unix script). I'm now launching the Java VM directly. I believe Process.destroy should work for Windows as well. This did however involve replacing a bunch of platform specific code, and I don't have a Windows machine to test on. I would appreciate it if anyone could check the latest build and let me know whether JRuby process termination now works (and more importantly, whether process -launching- still works...) You can force the old behavior (for now, until we find out whether this works) by adding -J-Druby.use.jruby.script=true to etc/netbeans.conf.
*** Issue 96700 has been marked as a duplicate of this issue. ***
Yes, it appears to work on windows. Thanks!
Perfect, thank you for the confirmation. By the way, do you have spaces in your path to the executable? (common on Windows with userdirs). If so I can close another bug too.
> I'm now launching the Java VM directly. Tor, one side effect of this change is that the JVM is no longer picking up the %CLASSPATH% environment variable, for example, derbyclient.jar. Is it still possible to configure the launcher you are now using for the Java VM?
I just checked in a fix (will be in Hudson build 681) where jars on $CLASSPATH will be passed to the JRuby VM. (There will also be a library customizer which will replace this, but this should hopefully be an easier interim solution.)
Reassigning this issue to newly created 'ruby' component.
Changing target milestone of all resolved Ruby issues from TBD to 6.0 Beta 1 build.