Bugzilla – Full Text Bug Listing
| Summary: | JVM service provider | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Igor Alelekov <igor.alelekov> | ||||||||
| Component: | TPTP | Assignee: | Igor Alelekov <igor.alelekov> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | blocker | ||||||||||
| Priority: | P1 | CC: | jcayne, jgwest, jkubasta, sluiman | ||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | closed460 | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 206878 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Igor Alelekov
Hi Igor, I've implemented a JVM service provider based on Samson's Java provider code as per your instructions last Thursday, e.g. I've removed the JVM xml references from the CCTL section of the serviceconfig.xml and moved them to the own separate element, as well as updating the loading code in the Configuration Manager, updating all remaining references to the old code, etc. I'll be posting the patch either today or tomorrow. Created attachment 87013 [details]
Patch to the Native AC Code
Created attachment 87014 [details]
Patch to SetConfig Configuration Java Files
The native patch isn't perfect: when applied, and you load the updated solution in VC6++, you'll get an error 'cannot access the classview information file', likely because I left out an NCB file. This is a minor problem, and the code compiles without incident. I'll include a separate patch shortly to fix the problem. SetConfig code is as expected. Patch summary is that it's Samson's JVM provider code, modified as per your email specs. Changes to the setconfig include removing the "'<Jvm>C:\Program Files\IBM\Java142\jre\bin\classic\jvm.dll</Jvm>" from the TPTPCCTL xml code, and now include a "<Jvm location="C:\Program Files\IBM\Java142\jre\bin\classic\jvm.dll'/>" as its own entry (at the same depth as, say, the <agent/> or <plugin/> tags). Changes to the native code are to reflect loading the configuration file changes, and the change to load the JVM only when needed (rather than in CCTL), and to have the Java class file and Java VM path set outside the CCTL code. Igor, can you take a look at the changes and see if they're in line with what you were expecting? Thanks! Hi Jonathan, Your implementation seems to have some questions: - Hiding jvm creation behind Attach() call, you are losing ability to set classpath, which each consumer can have. You see, your JSSE module will be packed in a jar file, which should be added to the classpath on the module initialization. - Your code is a windows specific and will cause a regression if will be checked into CVS. - Method tptpAtachCurrentThread() has memory leak. - The patch contains some unnecessary binaries. Igor has suggested that he should implement the JVM provider, as he is more familiar with the requirements, and I have agreed. I'll be hooking into his implementation with the JSSE security implementation. Just to review your comments quickly: "Hiding jvm creation behind Attach() call, you are losing ability to set classpath" -- The classpath is taken from the environment under which the AC is run (similar to CCTL implementation as you described in your email), or through a call to the TPTPEnv methods. "Your code is a windows specific and will cause a regression if will be checked into CVS." -- Yah, I'm not sure if Samson tested the JVM provider code on Linux. "Method tptpAttachCurrentThread() has memory leak." -- Good catch, Samson failed to free the thread args (and I missed it too). "The patch contains some unnecessary binaries." -- That one is my fault. The Eclipse patch generator is less friendly than I'd like ;) If you plan to reuse code from the provided patches, let me know if you want any changes to the above. Thanks. Created attachment 87151 [details]
implementation of jvm provider
Hi Igor, I see you are calling System -> SetProperty("java.class.path"...) in your JNI code.
It is noted in this Sun JVM bug report (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4791758) that "attempts to modify the class loader's classpath with System.setProperty() is entirely ineffective".
Likewise, "Though many system properties are read-only, the VM and the runtime system allow them to be set, sometimes with unpredictable if not disastrous results." (http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=885b6331525deeffffffffe0d8b862d9e0e22?bug_id=4165411)
This second bug, which the first dupes, is an enhancement which has not been fixed in any released Sun JVM.
Hi Jonathan, Our use case deffers from the reported in the bug - we are using Invocation API. This JVM bug is reported against 1.4.0. I have tested the patch with jvm 1.4.2 and it works good. Anyway, if we will get the ClassNotFoundException, we can use workaround (URLClassLoading.addURL()). I've completed review: Patch is good. The patch is checked into the 441 branch. Waiting for 4.5 build starting to check the patch into the HEAD. The patch is checked into the HEAD. Resolving as fixed. Checked in Patch to SetConfig Configuration Java Files to HEAD and 4.4.1 Branch. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since the originator of this enhancement/defect has an inactive Bugzilla account and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |