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.
Description: build 0317_2 Note: This use to happen when deploying webcentric services but george/nam fixed it with new apis. Steps Tail ide.log Start IDE Start UDDI server See this error: INFORMATIONAL *********** Exception occurred ************ at Wed Mar 19 10:02:16 GMT-08:00 2003 [catch]java.lang.Throwable: ExecInfo is deprecated - please use Executor.execute (DataObject) instead at org.openide.execution.ExecInfo.<init>(ExecInfo.java:42) at org.netbeans.modules.tomcat.tomcat40.Tomcat40Installation.createNewTo mcatProcess(Tomcat40Installation.java:926) at org.netbeans.modules.tomcat.tomcat40.Tomcat40Installation.startServer InExecMode(Tomcat40Installation.java:905) at org.netbeans.modules.tomcat.tomcat40.Tomcat40Installation.synchronize Start(Tomcat40Installation.java:1053) at org.netbeans.modules.tomcat.tomcat40.Tomcat40Installation.nonIncremen talDeploy(Tomcat40Installation.java:681) at org.netbeans.modules.tomcat.tomcat40.Tomcat40Instance.deploy(Tomcat40 Instance.java:267) at org.netbeans.modules.j2ee.impl.DefaultServerInstanceManager.doDeploy( DefaultServerInstanceManager.java:120) at org.netbeans.modules.j2ee.impl.DefaultServerInstanceManager.startDepl oyment(DefaultServerInstanceManager.java:147) at org.netbeans.modules.j2ee.impl.DefaultServerInstanceManager.serverIns tanceDeployment(DefaultServerInstanceManager.java:90) at org.netbeans.modules.j2ee.impl.DefaultExecPerformer.startDeployment(D efaultExecPerformer.java:80) at com.sun.forte4j.webdesigner.uddi.nodes.jwsdp.JWSDPUDDIServer.start(JW SDPUDDIServer.java:312) at com.sun.forte4j.webdesigner.uddi.nodes.StartServerAction.performActio n(StartServerAction.java:79) at org.openide.util.actions.NodeAction$DelegateAction.actionPerformed(No deAction.java:431) at org.netbeans.core.ModuleActions$1.run(ModuleActions.java:97) at org.openide.util.Task.run(Task.java:136) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:328) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java :668) Evaluation: xxx@xxxx 2003-03-19: I cannot reproduce this in build 0317_2. jdk 1.4.1_01. xxx@xxxx 2003-03-19: yes, this still happens on s1s nevada build 0318. this is due to netbeans tomcatint module is still using deprecated ExecInfo. If you deploy/exceute to jwsdp tomcat first, you will see the same exception in ide.log. the exception only show once during one ide session. i will attempt a BT-to-IZ transfer. The bug should be fixed in the open source. No code fix can be done in the s1s jwd module. A comment.
So does this exception appear only in the IDE log, or does it pop up in the user's face. In build 030319, it is only logged to the log file. So I don't understand the justification why this should be a P2 bug. I believe the correct priority is P4. Reassigning to Milan, who is responsible for this part of the Tomcat plugin. Setting target milestone to 4.0.
The ExecInfo class is really deprecated. The deprecated class is not sufficiently replaced by the Executor.exec() method. The Tomcat module uses a none-deprecated ProcessExecutor.Format class that uses the ExecInfo object as an argument in its constructor. Then the ProcessExecutor.Format object is used as an argument for NbProcesDescriptor.exec() method (also none-deprecated method in none-deprecated class). The steps how to replace the ProcessExecutor.Format class and NbProcessDescriptor.exec() method are not sufficiently explained in documentation. Is the deprecation of ExecInfo really proper here ? I noticed that lot of modules still use this class. Is there a document where can I read about how to replace that ?
I noticed that the ErrorManager writes to the log file only from the ExecInfo(String className, String[] argv) constructor. We can easily evoid of this by extending ExecInfo class and overriding getArguments () method.
Please do not override getArguments just to avoid the stack trace. Anyway it will not work since either constructor will print it. NbPD.exec takes java.text.Format. It's true, ProcessExecutor.Format should be deprecated too. You do not need it. I just committed a new version of ProcessExecutor that deprecates it and includes better instructions for overriding createProcess(DataObject).
Thank You Jesse for your hints. Code was changed in trunk. Diffs : http://web.netbeans.org/source/browse/tomcatint/tomcat40/src/org/netbeans/modules/tomcat/tomcat40/Tomcat40Installation.java.diff?r1=1.65&r2=1.67 http://web.netbeans.org/source/browse/tomcatint/tomcat40/src/org/netbeans/modules/tomcat/tomcat40/Tomcat40DataObject.java.diff?r1=1.50&r2=1.51
Note that whether or not to provide ArgumentsCookie is up to you - for some kinds of execution it makes sense, for others it doesn't. Depends on whether a user would plausibly want to add command-line params for a single executed object.
Actually calling ArgumentsCookie.setArguments from within code (other than org.netbeans.core.execution.SetArgumentsAction) is generally wrong. Here it is definitely bizarre usage. "start" or "stop" should be passed as constructor args to TomcatFormat, and probably there should be no ArgumentsCookie used at all (and use of Tomcat40DataObject in TomcatFormat is probably unnecessary). Also using ProcessExecutor.Format.TAG_CLASSNAME here is probably wrong because the class name is not intended to be replaced at runtime by something based on the data object; org.apache.catalina.startup.Bootstrap should be hardcoded into the default NbProcessDescriptor strings in Tomcat40DataObject.
New Task created (Issue 32506).
Verified in Nevada build 030401.
Jason, this bug was not fixed in Nevada, only trunk. Are you sure you don't see this in Nevada ?
Jesse, regarding the deprecated ProcessExecutor.Format and the recommendation to use own subclass of MapFormat: Would not it be useful to provide an API class which would extend MapFormat specifically for the purpose of launching the JVM ? I don't think launching the JVM is Java-centric, as many modules, which are not necessarily tied to Java development, might need to launch external Java programs. There are some useful things about ProcessExecutor.Format, namely the tags like TAG_CLASSPATH. The bad thing about ProcessExecutor.Format is the constructur which taked ExecInfo, and the calls to the deprecated NbClassPath methods. But other than that, I think a 'JVMFormat' base class would be useful.
Re. JVMFormat convenience class - I think that would make sense, yes. Feel free to file an RFE in openide/execution.
Done. See issue 32605.
Also fixed in the NB 3.5 branch (through the fix of 32589).