Community
Participate
Working Groups
Current ARM agent is developed based on the old AC execution framework. We need to upgrade this ARM agent to the new AC execution framework.
If this Bugzilla is planed to be completed in 4.5, please add the plan keyword. Otherwise, please target to future. In addition, if this Bugzilla is committed to be completed in 4.5, please change the priority to P1.
Two critical defects are depending on this defect, raising to critical and P1.
target milestone is changed with PMC approval
I'm working on this bug.
Created attachment 96840 [details] patch for 212009
Eugene, Joe, could you review the patch?
Richard, your patch detects java version locally getting System.getProperty(). This is incorrect. You should request remote Agent Controller for the JVM version. Some useful code you can find in the org.eclipse.hyades.trace.ui plugin.
Igor, thanks for helping review... but could you please tell me the method name or class name? It'll be quicker for fixing this defect.
PIDelegateHelper.JVMVersionDetector
In order to use JVMVersionDetector, we'll need to add org.eclipse.hyades.trace.ui as a dependency in org.eclipse.tptp.trace.arm. But this org.eclipse.tptp.trace.arm is deployed in AC side. Is it correct to add the dependency? I'm not sure. Since ARM agent works on AC side, it should be okay to use System.getProperty() to detect AC's java version. If I'm wrong, please correct. Thanks.
UI plug-in dependency should not be introduced on the AC side. Richard/Igor, Is there a way to get the JVM path value from the AC configuration file programmatically and simulate what is done in org.eclipse.tptp.trace.ui.internal.launcher.deleg.application.DefaultJVMVersionDetector. ie. run 'java.exe -version' for version value?
(In reply to comment #11) > UI plug-in dependency should not be introduced on the AC side. > Richard/Igor, Is there a way to get the JVM path value from the AC > configuration file programmatically and simulate what is done in > org.eclipse.tptp.trace.ui.internal.launcher.deleg.application.DefaultJVMVersionDetector. > ie. run 'java.exe -version' for version value? Currently config file hasn't jvm version. Recently during investigation of another bug I have implemented this - getting jvm version from the config file. But hasn't checked it into CVS yet. So the code can be applied if it is necessary.
Igor, it sounds like a very handy util to be included on the AC side.
(In reply to comment #11) > UI plug-in dependency should not be introduced on the AC side. > > Richard/Igor, Is there a way to get the JVM path value from the AC > configuration file programmatically and simulate what is done in > org.eclipse.tptp.trace.ui.internal.launcher.deleg.application.DefaultJVMVersionDetector. > ie. run 'java.exe -version' for version value? > Agreed. We should not introduce an UI plug-in dependency to the Agent Controller, especially for a common utility. In addition, the useJVMTI() will incorrectly return for 1.3.* and below JVMs.
(In reply to comment #14) > > In addition, the useJVMTI() will incorrectly return for 1.3.* and below JVMs. > Yes, the method useJVMTI() doesn't cover java version below 1.4, that's because TPTP 4.5 requires java 1.4 or above.
(In reply to comment #15) > (In reply to comment #14) > > > > In addition, the useJVMTI() will incorrectly return for 1.3.* and below JVMs. > > > > Yes, the method useJVMTI() doesn't cover java version below 1.4, that's because > TPTP 4.5 requires java 1.4 or above. > Correct, but the method should handle the corner case.
(In reply to comment #16) > > Correct, but the method should handle the corner case. > OK, I'll change code for this and create a new patch tonight.
moved to future with PMC approval
Mass update of P1 enhancements and defects targetted to future to P2.
Targetting to 4.5.3 based on Eugene's input.
Leaving at P2 for 4.5.3 pending Richard's input.
Targeting to future as requested by Richard since there's no resource to work on this for TPTP 4.6.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. Since this defect is more than 2 years old, it may be no longer relevant. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this defect is resolved as WONTFIX. If this defect is still relevant and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
This defect had been resolved as WONTFIX for more than 1 month. Closing this on the reporter's behalf. Please re-open if you have further comment on this issue.
Closed in TPTP 4.7.2.
