Community
Participate
Working Groups
Build ID: Eclipse 3.4.x Steps To Reproduce: The WebSphere Commerce product uses RAD v7.5.2 and is running into an error that is effecting the install and configure phase of the product. What the Commerce product does, is run RAD in headless mode to import projects into the workspace, configure preferences in the workspace and to publish our application to a WebSphere server. Normally this works properly but we're seeing that on many occasions the process fails with errors in either the EJB deploy code or in the application publish code. The owners of that code have investigated the problem and have come to the conclusion that calls to IJavaProject.getPackageFragmentRoots() will occasionally return an empty array instead of expected values. During all runs, the .classpath files are the same. More information: One idea is that there's a synchronization issue and some of the tasks the setup script runs, actually execute before the JDT has finished initializing. I don't have a simple testcase but can provide an internal IBM machine to help troubleshoot the issue. Since this issue is happening in the setup/config step and causing it to fail, we're going to need some kind of fix included in RAD v7.5.3 to get past this issue.
(In reply to comment #0) > Build ID: Eclipse 3.4.x > Steps To Reproduce: > Normally this works properly but we're > seeing that on many occasions the process fails with errors in either the EJB > deploy code or in the application publish code. Hello, What do you mean by "Normally this works properly" ? 1. So, in the set up you have now, without altering the setup in anyway if you run the experiment several times, do you see things working properly some of the times ? Or in other words, ignoring the actual failure *mode* for a moment, against the same setup do we consistently see failures ? or do things works ok some of the times ? 2. Alternately, did you mean that it works against some setup of project code, required plugins, projects, libraries and fails against some other setup ? 3. I am assuimg that this worked against some version of project code, required plugins, projects, libraries etc. Could you set up a working case and the broken case so the set up can be compared and played with so we know what introduced the regression ? 4. In order to make progress, you need to set up things so I can debug and step through JDT/Core code to understand what may be going wrong. What you have furnished now, just goes to show there is some problem, but is not useful to debug the problem. How do I see this problem inside an eclipse debug session ? As a specific case, if I want to be able to step through the method IJavaProject.getPackageFragmentRoots() to see why it returns empty [], how would do I this in your set up ? Since I know next to nothing about RAD and ejbdeploy etc, we need the following to make quick progress: 1. A setup where I can launch some debug launch configuration and observe the problem, (empty array being returned, or an exception being thrown etc) 2. A setup where I can launch some debug launch configuration and observe that things work ok. 3. In both 1 & 2, JDT/Core plugins are available with sources (i.e, the SDK versions and not the runtime versions which lack sources)
I'm capable of running the exact same setup multiple times and sometimes everything is successful while other times it fails. I haven't found a specific pattern to why it fails. This problem has existed in some form since moving to RAD v7.5.x (Eclipse 3.4.x) but there have been times in which it happened more often than other times. Because of our dependency on some of the RAD plugins I don't have an environment that is Eclipse only or a testcase that can be run in a simple launch. What the other groups that have debugged the problem have done was to produce class files with extra debug code, patch the system and rerun the test. I'm not sure that this can be done with a launcher, but I suppose if one were created with the exact parameters of the ANT script, it might reproduce the problem.
(In reply to comment #2) > I'm capable of running the exact same setup multiple times and sometimes > everything is successful while other times it fails. I haven't found a > specific pattern to why it fails. I ran it several times today - each time the build was successful. I am afraid this "here is the whole setup, debug this" approach is not going to help speedy resolution - Given each run takes 25 minutes and most (in my experience today - all) runs are successful, (assuming coming up with a smaller reproducible case is a lost cause) we are going to have to the squeeze out the time taken for each attempt at reproduction. Could you engage some experts who know the whole setup to see if they can hoist some loop invariant operations outside of the loop ? For example you say sometimes the failure is in the publish code - can the ant scripts be split into two pieces : one that does everything before publish (which we can run once) and the publish piece alone which can be run repeatedly - I don't know that this is possible or even a meaningful request, but we need to do something to cut down the time to repro and what this something is, is best decided by someone who knows the whole architecture here. > This problem has existed in some form since moving to RAD v7.5.x (Eclipse > 3.4.x) but there have been times in which it happened more often than other > times. > Because of our dependency on some of the RAD plugins I don't have an > environment that is Eclipse only or a testcase that can be run in a simple > launch. What the other groups that have debugged the problem have done was to > produce class files with extra debug code, patch the system and rerun the >test. > I'm not sure that this can be done with a launcher, but I suppose if one were > created with the exact parameters of the ANT script, it might reproduce the > problem. Here is how to debug this case: 1. By tweaking the JVM invocation within setenv.bat to have additional arguments -Xdebug -Xnoagent -runjdwp:transport=dt_socket,server=y,suspend=n,address=8000 we can get the JVM to wait for a debugger to attach to it. 2. I have loaded eclipse 3.4.2 into C:\Srikanth and created a workspace with jdt.core source projects of version v895_r34x used by the WAS/RAD setup. 3. C:\Srikanth\workspace has debug launcher for eclipse remote application called DebugJdtCore. 4. I have a breakpoint in JavaProject.getPackageFragmentRoots() at the return statement with a condition that says roots.length == 0, this never triggers. 5. I also have a breakpoint at SetClasspathOperation.executeOperation which doesn't trigger either - so there aren't any programmatic changes happening to class path.
Has this been tried on 3.5 ? bug #270287 comment #4 sounds very similar. That issue is supposedly fixed on 3.5.
Setting target to 3.5.1. It would be nice if this could be checked on 3.5RC4. If it works, then this issue should be closed.
Just to provide some info, we've been testing with the latest version of RAD v7.5.3 which I understand contains a number of synchronization fixes in this area. So far things are looking promising. As for testing on Eclipse 3.5, that isn't possible. The WebSphere Commerce product requires the RAD application to function and as such we can't test with bare Eclipse.
(In reply to comment #6) > Just to provide some info, we've been testing with the latest version of RAD > v7.5.3 which I understand contains a number of synchronization fixes in this > area. So far things are looking promising. What version of JDT/Core is used in this version of RAD?
org.eclipse.jdt.core_3.4.5.v_895_R34x.jar
Removing target. This seems to be a problem with 3.4.2 and we don't even know if this is still an issue with 3.5. Reducing severity. Is it still an issue as you mentioned in comment 6 that testing is looking good?
(In reply to comment #9) > Is it still an issue as you mentioned in comment 6 that testing is looking > good? We weren't able reproduce this issue in our tests. We haven't rolled out RAD v7.5.3 yet due to other reasons but I think this issue can be closed.
Closing as WORKSFORME.
Verified for 3.6M2
