Community
Participate
Working Groups
This is a regression of bug 376506. The code clearly returns (ie does nothing) if the name IS valid, rather than if it isn't. Please check ./plugins/org.eclipse.wst.server.ui/serverui/org/eclipse/wst/server/ui/internal/wizard/page/NewManualServerComposite.java if (validate(selectedServerType)) { // Do not set the server name if it is invalid return; }
Some effects of this bug are as follows. The first and most obvious is: 1) In a new workspace, try to create a server with a different name. The server will invariably be created with the default name. 2) Have a workspace with a server named MyServer alread. Try to create a new server named MyServer2. When finish is pressed, no server will be created at all. For #2, the reason is that the name is only updated when the value is INVALID. So when typing MyServe, the name never gets updated. At MyServer, the value is invalid, so the name is persisted. Adding "2" at the end does not update the name. So the final name is MyServer, which is a duplicate.
A github commit demonstrating the fix is here: https://github.com/robstryker/eclipse-webtools-servertools/commit/53219e8284a62067f2a92eabac9162d31d8ff0ac
Created attachment 221826 [details] reverses the incorrect validation flag patch attached
This is a regression discovered via swt bot tests at JBoss Tools: https://issues.jboss.org/browse/JBIDE-12725
I would argue that this issue is severe enough for a patch build to be put on a publicly available update site. The intention of the original issue was to block users from creating a server with a duplicate name. The fix incorrectly now forbids assigning any new name. It stands to reason that the fix was worse than the original problem, and that justifies a patch build in my mind.
Code released to master. Rob, can you confirm on which release are you seeing this problem? You marked the defect as 3.3 but the defect 376506 has just been port to the 332P last night. Therefore, it shouldn't be in any of the released driver on 3.3 stream yet.
Sorry for the mislabel. I blame the default value being 3.3 ;) I am experiencing this in the Juno SR1 stream. 671 ACTIVE org.eclipse.wst.server.ui_1.4.1.v20120821_1330 I feel this is important enough to demand a patch build to be published on a webtools update site. I think it was a mistake to push this into SR1 without proper verification, but hey, it's software, and mistakes happen. But some server types may try to forbid server renames after creation through a variety of mechanisms, and the inability to set an initial name is a big hinderance to such server types.
Also, is there a reason servertools bugzilla entries don't have maintenance versions in the version? It's pretty limiting when targeting bugs.
The reason that servertools doesn't have the maintenance release is because the previous owner doesn't create those. However, I agree with you that it is better to have the full list of targets. I have created the latest versions and set the version on this one to 3.4.1. Thanks for suggestion.
Created attachment 221925 [details] v1.0 Looks like there is a problem with the format of the patch that prevents the patch to be applied. Updating the patch with the same changes.
(In reply to comment #7) > Sorry for the mislabel. I blame the default value being 3.3 ;) > > I am experiencing this in the Juno SR1 stream. > 671 ACTIVE org.eclipse.wst.server.ui_1.4.1.v20120821_1330 > > I feel this is important enough to demand a patch build to be published on a > webtools update site. I think it was a mistake to push this into SR1 without > proper verification, but hey, it's software, and mistakes happen. But some > server types may try to forbid server renames after creation through a > variety of mechanisms, and the inability to set an initial name is a big > hinderance to such server types. I agree this is an important fix. Just to clarify that when the change for bug 376506 is pushed to SR1, we did tried our best to verify. If you check comment #1 on bug 376506. It has been verified with fairly thorough list of tested scenarios (obviously we are still missing this important one :( ). Unfortunately, our existing JUnit does not cover this scenario for which we should revisit that short coming in the existing test suite.
Hey Elson, just curious here. What are the chances we can have a patch build for this put up somewhere publicly accessible?
I am working on it.
I am requesting approval for making a public patch on 3.4.1 code stream available for the fix on this problem: 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 problem is a regression introduced on 3.4.1. The problem does not exist on 3.4. This bug causes a server cannot be created with a name different from the default name. The adopter has requested a public patch given that it is a very common scenario so the user is likely to hit this problem the work-around does not work in their case (see work-around section for details). Is there a work-around? If so, why do you believe the work-around is insufficient? The user can work-around the problem by renaming the server in the server editor after the initial creation. However, one of the adopter has indicated that they have got a case that their server type forbids the user from renaming a server after the initial creation. Therefore, this problem will be a big problem to their server type. (see comment 7) 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 scenarios described in this defect as well as the scenarios that involves default server creation to make sure there is no regression introduced by this problem. Give a brief technical overview. Who has reviewed this fix? The fix is a one line code change to make sure the correct condition is tested in the code path to meet the original intention of the fix. The originator has submitted the defect and Elson have reviewed the patch. What is the risk associated with this fix? Fairly low since the fix is restricted to the server creation wizard and the code change involved is very simple.
approved
hey Elson: Any updates on if there's a schedule for the public patch? The issue is still 'assigned' so I'm just curious what goes on behind the scenes now :)
I set up the WTP 3.4.1 patch build stream, but got sidetracked after that. We just need to commit the appropriate content, do a patch build, and then add that patch build to the public webtools/juno repository. (So I'm the one that is holding things up right now.)
Changes released to R3_4_1_patches stream.
The patch is located at: http://download.eclipse.org/webtools/patches/drops/R3.4.1/P-3.4.1-20121112163420/ Once it is verified that this resolves the problem, I will add this patch to the public Juno repository.
I verified the fix with eclipse-jee-juno-SR1-win32-x86_64.zip with the patch installed and using a non-default name with Tomcat 7. I also verified that if I put a duplicate server name, validation would occur (changes for bug 376506)
New Gerrit change created: https://git.eclipse.org/r/109133
