Bugzilla – Full Text Bug Listing
| Summary: | ClassCastException: PassthruResourcesEList incompatible with SynchronizedResourcesEList | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | Carl Anderson <ccc> | ||||
| Component: | jst.jem | Assignee: | Carl Anderson <ccc> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | david_williams, deboer, jsholl, kaloyan, raghunathan.srinivasan | ||||
| Version: | 3.2 | Flags: | david_williams:
pmc_approved+
deboer: pmc_approved? ccc: pmc_approved? (naci.dai) deboer: pmc_approved+ ccc: pmc_approved? (neil.hauge) kaloyan: pmc_approved+ ccc: review+ |
||||
| Target Milestone: | 3.2.1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | PMC_approved | ||||||
| Bug Depends on: | 319772 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Carl Anderson
Another part of the proper fix- there is no reason why PassthruResourceSet's PassthruResourcesEList cannot extend SynchronizedResourcesEList. In fact, it gains a lot of benefits by doing so. However, since we cannot guarantee that all extenders of ProjectResourceSetImpl will return an implementation of SynchronizedResourcesEList, we need to check the type in getImmutableResources(). Created attachment 175442 [details]
Check the type before casting
To be clear, in WTP 3.2.1, two methods in EMFWorkbenchEditPlugin, createIsolatedresourceSet() and createWorkspacePassthruResourceSet(), now return ResourceSets that will cause this ClassCastException. There is no workaround. The exposure of this to end users: If an adopter product attempts to load a resource based off of a PassthruResourceSet, it will get this ClassCastException and prevent the resource from being loaded. This will appear to the user as an empty resource, whereas there may have been a resource to load. Furthermore, this is an exception that is not caught by our code. Thus a dialog may be surfaced to the end user with this exception, or it may just be caught and logged. 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. As noted before, this causes ResourceSets that were previously supported/working (including PassthruResourceSet in WTP) from being able to load resources. In the adopter case, this will keep proprietary extensions and mappings associated with common Java EE modules (especially EJBs) from loading. This effects manipulation of the projects, including deploying them on proprietary servers (since the necessary extension and mapping information is not loaded). Is there a work-around? If so, why do you believe the work-around is insufficient? There is no workaround. How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? This has been tested by hand and by providing a quick test fix that the adopter product has tested. Give a brief technical overview. Who has reviewed this fix? The fix consists of two parts: Checking the class of the EList before casting, and updating PassthruResourceSet to use a SynchronizedResourcesEList for its resources. (Note that that is not a new class - SynchronizedResourcesEList was added in WTP 3.0.x to help protect the resource set from ConcurrentModificationExceptions. PassthruResourceSet will benefit from that additional protection.) Neeraj Agrawal has reviewed this fix. What is the risk associated with this fix? This is a relatively low risk fix, but it is in a high-usage and high-importance area. (As can be seen by the "simple" change in bug 319772 that broke this.) For the record, Chuck is on vacation, and I am his delegate for these matters until his return on 8/4. Looks like a completely safe patch. Unfortunately a very serious regression for adopter product/function. While wouldn't appear in WTP all by itself, I'd prefer to fix this for 3.2.1 rather than build an immediate patch. I'm not sure, though, under what conditions other adopters might hit this same problem, if/when they begin to pick up this service release? I think this last minute respin is feasible, but only because we are not part of a "simultaneous release" stack for this off-cycle maintenance ... though any rebuild this last minute introduces risk and logistical problems. (e.g. we'll have to re-mirror build distribution and repository). Committed to HEAD for WTP 3.2.1 and WTP 3.3 |