Community
Participate
Working Groups
We are seeing this in an adopter product. It is a rather complex scenario, but the end result is that the EARLibraries classpath container is missing entries. During the build of the dependency graph, several projects are queued up to recompute. Now, while going down a project towards the begining of the list, during the dependency recomputation, the classpaths are recomputed to pickup loose dependencies, this causes a project later in the original list to compute its classpath, which it does incorrectly because it's true dependencies haven't yet computed. Attaching a stack to show the code path. After looking over the code, it turns out that the getJavaClasspathReferences() call that is causing this problem is not necessary for the purpose of building the dependency graph. The dependency graph only track reverse project dependencies, and getJavaClasspathReferences() builds archive dependencies which aren't used here. The fix is relatively simple. Created a new method for getting references which takes an options map. The default behavior is the same. The only place this new method is called is from the dependency graph, and it passes in the options necessary to avoid the above calls.
Created attachment 109940 [details] stack trace
Created attachment 109941 [details] patch
* Explain why you believe this is a stop-ship defect. Or, if it is a "hotbug" (requested by an adopter) please document it as such. This is a regression from previous releases. When the user starts an existing workspace, suddenly their projects don't build. * Is there a work-around? If so, why do you believe the work-around is insufficient? The EARLibraries classpath container can be refreshed with a context menu under Java EE. Most users don't know this exists, and it is not a viable solution. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? This fix has been tested with the UI. JUnits will be run later and binary patches will be distributed. * Give a brief technical overview. Who has reviewed this fix? See above comments * What is the risk associated with this fix? By not forcing the load of JDT upfront, the timing has been changed; this could lead to other race conditions.
Created attachment 109942 [details] patch adds an instanceof check on the off chance another adopter has overridden the VirtualComponent implementation.
Approved - have reviewed race condition/re-entrant code issue, and new options will prevent calculating the getJavaClasspathReferences
I've just glanced at the code, (so don't know if it's simple and safe) but it does sound like there is a work around for this one. Granted, not the greatest, no one ever likes workarounds, but I think that prevents it from being stop ship. This only happens with existing workspaces? Or existing projects? Also, is that hard to find menu you mention the only work around? What if they just started/imported again ... will it work sometimes, sometimes not? Will a "refresh" help, a 'rebuild'? how about close and re-open the project? Again, this is obviously important, and I'm glad you have a fix ready, but I'm just trying to better understand if it's feasible to put off until 3.0.2 in order to minimize further change. Thanks,
Ok moving to 302
Pulling back to 3.0.1 because this is a bad scenario for users. When a user's workspace hits this code, yes there are various twiddles that can be done to force the classpath to update. Though I haven't tried it, my guess is closing and reopening projects would work. Cleaning/rebuilding/restarting will not work; once the user is in the bad state they will hit it again and again. Our users do not like workarounds like closing/reopening projects or finding a menu item which is why I'm pushing for 3.0.1. This is especially bad because users on previous WTP based products could run into this when they upgrade without changing anything in their workspaces.
Spoke with Chuck; moving back to 302
patch applied to 3.0.1 patch and 3.0.2 ... be sure to carry over to HEAD.
*** Bug 243398 has been marked as a duplicate of this bug. ***
This was released to HEAD for 3.1 on 9/4.
Reopening bug.... This fix was reverted as a result of: https://bugs.eclipse.org/bugs/show_bug.cgi?id=245645 but no follow-up was opened. Will target this to 3.0.4
The fix may have been reverted, but we are not currently hitting this in the adopter scenarios, so I am re-closing this for now.
Reopening; still hitting this problem with 3.0.4.
Created attachment 127561 [details] patch for 3.0.4
The problem with this bug, is there is a cyclical dependency between the classpath computaiton and the dependency graph. This causes update issues, especially when restarting the workbench. The first thing that occurs during a restart is all the EAR Libraries classpath containers are recomputed by JDT. These containers need to know what EAR they are part of which kicks of the Dependency Graph to compute. While the Dependency Graph is being computed, it asks each module what its dependencies are; however to do this, the classpath is needed. :) The first half of the fix is to relax the initial computation of the dependency graph so it does not require the classpath (only during the first build). After the first build of the graph the option to ignore classpaths is turned off and a rebuild is immediately scheduled. The second half of the fix is to not require the EAR Libraries classpath container to need to compute references based on classpaths when computing itself. There was never a need to do this, and this was simply over looked. This is not necessary because the EAR Libraries classpath container will never add a duplicate classpath to itself (so why bother finding these references only to sift through and remove them later?).
I sat down with Jason to go over these problems, and after talking through the issues of this scenario - we realized taking two passes is the way to go - 1st eliminating the need for a cyclical call needing java classpath info when calculating component dependencies, and then a second pass including these classpath dependencies after the initial resolution on startup is complete. Jason has run through our junit bucket + ran regresing scenarios noted in this bugzilla
Note that the last patch is for 3.0.5. (Since it was attached after 3.0.4 became publicly available.)
Committed the "patch for 3.0.4" to R3_0_maintenance for 3.0.5 and HEAD for 3.1
