Community
Participate
Working Groups
When we import an EJB jar using the 20050916 WTP 1.0 M8-based driver and server target it to a runtime containing a large (about 50MB) jar, some types inside this jar cannot be reflected using JEM or JDT after the project is created. In addition, we perform the import in headless Eclipse. Examining this issue, we opened the workspace containing this project inside the Eclipse UI and, when we expand the jar in the package explorer, it shows some packages with a "?" icon. If we try to open the types which couldn't be reflected in JEM/JDT, we got a Select Type dialog popup error message that states: Could not uniquely map the type name to a type. If we move this type to a smaller jar also on the server target then JEM/JDT reflection seems to be ok. Note that if we manually server target using the GUI, this problem does not seem to occur. I don't know if this is a server targeting, EJB jar import or JDT issue
I think this is a JDT problem. The Server Target mentioned above is a classpath container containing all the jars available to the Server during runtime. In this case one of these jars is large (aabout 50MB).
We need a patch for this on top of Eclipse 3.1 as soon as possible.
We need a test case with steps to reproduce. 3.1.1 RC3 build is tomorrow. Why didn`t we get a PR before if you got it first using build from the 20050916?
Removing target milestone. It will certainly not meet 3.1.1 which is happening in a few hours. In order to address this defect, we first need accurate steps to reproduce. We may provide a patch once the problem is addressed. Did the problem occur in 3.1.0, or are you telling it is a regression from 3.1.0 ?
Jerome - Feels related to bug 102422, which got addressed for 3.1.1. Could it be a different path in the code ?
Yen - can you check which version of JDT/Core is installed in: 20050916 WTP 1.0 M8 ? If this tells 3.1.0, then it is likely a dup of bug 102422, for which we already have a fix scheduled for 3.1.1. Could you give it a try ? Assuming it is the case, could you grap an Eclipse 3.1.1 build (rc2) and see if when applying it to your WTP build, it addresses this issue ?
Philippe, Olivier pointed me to Bugzilla 106202 which I have delta-applied on top of org.eclipse.jdt.core_3.1.0.jar. We run with -Xmx256M. I did not have to change this value when retrying my testcase. It passes now but do I really need both 106202 and 102422? I want to make the smallest change possible since our deliverable must ship as soon as possible.
Indeed this bug sounds more like bug 102422 (where the jar was flushed from the cache while opening it). Bug 106202 is about performance, it won't have any effect if you run with -Xmx256M as this is the default value for Eclipse. So all you need is the fix for bug 102422 I believe. Can you please confirm that ? If you still have the problem with the fix for bug 102422, then we need a test case to reproduce. Also note that if you take Eclipse 3.1.1 (M20050928), you will get fixes for both bugs.
The bug I wanted to point you to is bug 102422 and not 106202. My mistake.
Applying the patch for 102422 helped. However, in our overnight BVT run of 1200+ invocations of this headless application, the problem occurs sporadically and, in total, about 4% of the time. I can reproduce it quite readily in a sequence of 100 runs but it is random and there's nothing in the .log file which helps me pinpoint the cause.
Can you explain in what the patch did help ?
Prior to the patch, this failed consistently and on both Windows and Linux. With the patch, I have not run into this problem since on Windows even with several batch runs of our tool. On Linux, if I set up a batch run of our tool for say 100 times, the failure to introspect occurs about 4-8 times on average. I'm working to set up remote access for Jerome and modifying our code to be more JDT friendly.
After several attempts at making a JDT friendly test case, I believe this is no longer a JDT issue. You can close this bug. Thanks, Yen
Thanks for letting us know. I'm closing this bug then. *** This bug has been marked as a duplicate of 102422 ***
