Community
Participate
Working Groups
Created attachment 210788 [details] patch We are building a server adapter that defines the one runtime type and two server types attached to it. If I go to Window > Preferences > Runtime Environments > Add then the New Server Runtime Environment wizard pops up. Our runtime type is preselected and the "Create a new local server" checkbox is visible. If I click on the checkbox it disappears. The same happens if I change the selection. The checkbox does not appear again for this runtime type. After some debugging in the code I found out the the current logic in the WTP Server Framework is to show the checkbox only if the selected runtime type has only one server type attached. In the case of our runtime which has two server types, the checkbox should not appear. I found the root cause to be in the RuntimeTypeComposite.setVisible() method. There a call for setting the initial selection is done, which calls the NewRuntimeComposite.handleServer() method which controls the visibility of the checkbox. For some reason this does not work properly if this call chain is done synchronously. If the setVisible() method sets the initial selection asynchronously everything works as expected. I am attaching a patch that solves the issue.
I would like to raise this as a hotbug for Indigo SR2. The bug is not a major one for the community as a whole, but it affects an adopter's product of SAP in a negative way. We have some reports from users who are confused by this behavior and have the impression that our product is fragile. It's very likely that this issue exists for years. However, we are building a server adapter with two server types for one runtime for the first time. This is why we haven't noticed this issue before. The patch attached should be very safe and we hope it can go into the RC phase of Indigo SR2.
Created attachment 210820 [details] v1.0 This new patch is based on the original patch with handle cases like widget is disposed scenarios properly.
* 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. It is a hotbug requested by adopter since it causes confusion to the adopter's product. The checkbox may disappear upon clicking. * Is there a work-around? If so, why do you believe the work-around is insufficient? In the specific scenario, the user will click on the checkbox and the checkbox will disappear. The user can ignore that and no workaround is required. However, there is no workaround that allow the adopter to no show the checkbox in the first place. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? No JUnit has been added since it is specific to the adopter's scenario. I have tested the tomcat case. * Give a brief technical overview. Who has reviewed this fix? The problem is caused by the NewRuntimeComposite.setVisible() method call is sometimes getting called on a non-UI thread as a result of the initial defualt selection. The fix is to wrap the initial selection code by getDisplay().asyncExec. Elson has review the fix. * What is the risk associated with this fix? The risk on this change is fairly low as there is no change in the actual design of the runtime creation wizard.
This has my vote after Elson's vote - and respin of the patch
Code released to 33M and HEAD.
New Gerrit change created: https://git.eclipse.org/r/109096
