Bugzilla – Full Text Bug Listing
| Summary: | ServerDelegate not updated with current server | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP ServerTools | Reporter: | Tim deBoer <deboer> | ||||
| Component: | wst.server | Assignee: | Angel Vera <arvera> | ||||
| Status: | NEW --- | QA Contact: | Angel Vera <arvera> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | eyuen7 | ||||
| Version: | 3.2 | ||||||
| Target Milestone: | Future | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | plan_draft_332 | ||||||
| Attachments: |
|
||||||
Having done more testing, I've hit this bug in several ways. It's clear to me now that it is not safe to have *any* instance data in the delegate, since the delegate is neither notified when it becomes invalid nor has any way to check if it is. Since instance data is both useful and allowed under the contract, this is a serious defect. I wouldn't be surprised if a poll of all server adapters would turn up a couple that fail randomly after creation or saving, and others with strange code used to work around the problem. Raising the severity since this can easily cause major loss of function (e.g. unable to publish to server). |
Created attachment 192497 [details] Proposed patch During server creation, a server working copy is created, along with a delegate. When it is saved, the delegate is passed to the newly created server, but it is never passed the new server information. As a result, it is still working against the properties of the old working copy. The same problem exists after editing and saving a server - the delegate is left with the old working copy and won't know about any future changes. Said another way, clients who use the server delegate after any change may get stale data: old server attributes, etc. The only workaround is to restart the IDE, thus flushing the delegate. Patch is attached; the only drawback to this simple fix is that the delegate's initializer will get called again. This could be viewed as a problem or a benefit, depending on whether delegates aren't expecting the method to be called multiple times, or require the method to be called since the underlying server has changed. In my case either is fine, but I lean toward the later - otherwise there is no indication to the delegate that it should flush any cached data.