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've got a Spring3.2.3 based Java executable application. The application also instantiates a spring ScheduleTask. I recently updated my Netbeans to 7.3.1 version and every time I run my application netbeans seems to initiate another JVM instance to run the scheduledTask and stopping the application via the Output tab seems to stop the only the main application but the ScheduleTask seems to be running. So to stop the ScheduleTask I had to manually kill the process. To confirm this is a Netbeans 7.3.1 issue I switched batch to 7.2.1, and 7.2.1 did not instantiate another JVM.
NetBeans does not care about Spring ScheduleTask at. The IDE starts the application in a new JVM instance with cmd line arguments given in project.properties. The actual command line is visible when you run the application with ant verbose (debug). Please attach the ant verbose output (Tools/Options/Java/Ant/Verbosity Level). Thanks!
On Mac NetBeans/Preferences//Java/Ant/Verbosity Level
The verbose setting does not seem to be working on Netbeans 7.3.1 but is working on Netbeans 7.2.1 on Mac. I thought maybe there's a problem with my installation. So I delete Netbeans 7.3.1 application file from my Applications folder and deleted the following folders library/application support/netbeans/7.3.1 library/caches/netbeans/7.3.1 installed 7.3.1 again and when netbeans asked to import setting from the older version I selected 'No' this time. Ran my project again and the same problem exists, Netbeans seems to be starting a new Java instance for scheduling and Verbose flag is not working either. But verbose works for 7.2.1. What could be the problem ? I'm using Mac snow leopard 10.6.8
It's a maven project.
>It's a maven project. The Ant verbose works just with Ant project. The execution for Maven project is done by mvm.
Created attachment 136925 [details] -verbose attached verbose.txt is the initial output of -verbose flag
(In reply to comment #0) > To confirm this is a Netbeans 7.3.1 issue I switched batch to 7.2.1, and 7.2.1 > did not instantiate another JVM. that is because in 7.2 Compile on save is on by default, while in 7.3 it's off by default. The difference means that in 7.2 Run action is often (not always) performed by Ant (via the JavaRunner API) not maven. With Compile on save off, it's always run via maven. Please note that in upcoming 7.4, Maven is always used for execution no matter what CoS setting is set for the project. Ant build doesn't spawn a new java.lang.Process while Maven execution does. When performing cancel we use the ExternalProcessSupport.destroy() which should either use Process.destroy() to kill or some additional nb.org implementation that would attempt to kill all subprocesses that inherited the environment from the maven build jvm. So either there is something wrong with the algorithm or the spawned jvm doesn't inherit the environment and is missing the marker env var used to identify processes to kill. reassigning for evaluation. Please note that a sample project demonstrating the problem would help.
Created attachment 136937 [details] Netbeans 7.3.1 maven scheduledTask project test file I've attached a test project. If you run the Main.java class and check your processes in Activity Monitor on Mac you can see it starts two Java instances and when I hit click stop button in the Output tab in Netbeans the 2nd java instance is still running.
Created attachment 146157 [details] sample project demonstrating the issue The problem was present for NetBeans 7.3.1, 7.4 and is still present in NetBeans 8.0. It wasn't that problematic with jdk7 because there was another dock item allowing easily killing the running java process but with jdk8 there is no additional item hence need for looking for process id and killing it manually because "stop" button doesn't work and leaves running JVM. Here is attached simple Maven process to illustrate. Unpack, open in NetBeans, Run it (either whole project or just the file), use the stop button to end it. Console output: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cd /Users/wojtek/dev/tmps/NoStop; JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home "/Applications/NetBeans/NetBeans 8.0.app/Contents/Resources/NetBeans/java/maven/bin/mvn" "-Dexec.args=-classpath %classpath nostop.NoStop" -Dexec.executable=/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/bin/java -Dexec.classpathScope=runtime -DskipTests=true org.codehaus.mojo:exec-maven-plugin:1.2.1:exec Running NetBeans Compile On Save execution. Phase execution is skipped and output directories of dependency projects (with Compile on Save turned on) will be used instead of their jar artifacts. Scanning for projects... ------------------------------------------------------------------------ Building NoStop 1.0-SNAPSHOT ------------------------------------------------------------------------ --- exec-maven-plugin:1.2.1:exec (default-cli) @ NoStop --- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Observation - after starting the process I can see "Launcher" in running java processes: wojtek@atlantiscity ~/dev/tigase $ jps 2358 Launcher 2361 NoStop 2362 Jps 1915 Main After stopping the application from NetBeans only the launcher process stopps: wojtek@atlantiscity ~/dev/tigase $ jps 2361 NoStop 1915 Main 2363 Jps
Seems to be duplicate of issue #245474. *** This bug has been marked as a duplicate of bug 245474 ***
I've tried latest Beta available on main netbeans page and the issue still persists - as per #245474 - using maven-exec to run application (which is default method in NB) causes running new process (actual application) and upon stopping the execution from the IDE mave-exec is killed but the new process persists.
Interestingly - it works when the project is run with "Debug" instead of "Run"
*** This bug has been marked as a duplicate of bug 253517 ***
This issue is not resolved. The new issue is, well... newer than this one so why this one is marked as the duplicate?! This issue is still present it recently released 8.1.