Community
Participate
Working Groups
using wtp3.0RC1 20080516071848 sdk Using XMLExamples, I tried to find references to CommandSheet element in SpaceWarGame.xsd. It should find a reference in SpaceWarGame.wsdl, but the search resulted in 0 matches. Same if trying to refactor the element, it is not found inthe wsdl file. This worked in wtp3.0M7 20080506040630 sdk so this is a regression.
Keith, let's try to investigate and address this regression for RC2.
Since it's raining and this long weekend's compromised :-) I figured I'll try to reproduce this problem with a more recent build: wtp-sdk-S-3.0RC1-20080518072051 and IBM JDK 1.5. Here's what I did: - download the zips - extract the platform zip - extract the other zips in this order: dtp, emf, gef, wtp, xsd to the drop-ins folder - start the platform on a new workspace and with -clean - create the XML examples project - open the schema SpaceWarGame.xsd and search for references to the global element ResultSheet This won't work: the search shows zero results, instead of the one reference in the associated WSDL file. If I shut down the platform and start it up again, the references search between XSD and WSDL will start working. So I sparked up the debugger to figure out what was going on. It turns out this is what appears to be quite an insidious bug in the wst.common.core search engine surfaced perhaps by the difference in the order the platform reads extensions the first time it starts, compared with the subsequent times. The bug in the search engine is that the search participants order seems to affect the search results. In SearchEngine there are two loops: the first loop locates the target documents and the second does pattern matching. The first loop calls beginSearch on each search participant to re-initialize the search pattern's child patterns. The matching loop is stuck matching by using whatever search pattern children were contributed by the last participant invoked in the search loop. This bug does not surface if the XSD search pattern is first and the WSDL pattern is last, because the WSDL search pattern happens to extend the XSD one (WSDL has inline schema). The suspected difference in reading extensions between the first and subsequent platform starts makes the order unpredictable: the first time around it is WSDL followed by XSD, and subsequently XSD followed by WSDL. I'm going to attach a patch that seems to address the issue. Of course, we need to test extensively and, if the participants order change is really a result of the order the extension are being read, let the platform team know.
Created attachment 100835 [details] Tentative fix
While the tentative fix does solve the issue, it may introduce others because we have no idea what a search participant does in beginSearching. I'll have to think of a better fix.
Created attachment 101643 [details] More ideas This patch is more involved. It tries to use the search options map as a temporary storage for the XML search child patterns and tries to keep everything stateless. It mainly changes internal classes and the SearchEngine. Just posting it as a possible alternative, not necessarily a final fix.
Created attachment 102025 [details] Proposed fix This patch incorporates Craig's suggestions to bring the previouse patch conceptually closer to the original design. It adds two new methods to the XML component search pattern to mirror the old get/setChildren methods. These new methods take a search participant as parameter, making sure the participants don't override each other's child search patterns.
You need to have xml.core and wsdl.ui in your workspace when applying the patch. Moving the bug back to wst.xml because the latest patch does not touch wst.common code anymore.
Reviewed. Tested and looks good.
Created attachment 102067 [details] Patch Minor javadoc improvements and backwards compatibility change.
PMC, please review and consider approving this fix for RC3. * 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 bad defect that has managed to stay hidden for a long time because it was camouflaged by the search provider extension point reading order. The recent P2 changes seem to have changed the extension point reading order (which was never API) and exposed this bug. Please see comment #2 for a detailed description of the problem. The defect blocks the search and refactoring for XML schema components referenced from WSDL documents. This is a commonly used function when working on WSDL/XSD first web services scenarios. The defect is also a major defect for an adopter product (IBM) built on top of WTP. * Is there a work-around? If so, why do you believe the work-around is insufficient? The user would have to manually search for these references and if needed update them. This is error prone because a simple textual search and replace does not consider the interdependencies between WSDL and XSD documents. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? The test has been manually tested both in WTP as well as in the adopter product. I have also opened bug 234043 to track the need to add JUnit tests for this function. * Give a brief technical overview. Who has reviewed this fix? The proposed fix deprecates the old way the search participants were using to register the child search patterns and introduces two new methods to allow the XML component search pattern to store child search patterns for each search participant, for the current search session. The XML (and indirectly XSD) as well as the WSDL search participant were modified to use these new methods. Any search participant not using the new methods would still be able to use the old methods. The new methods delegate back to the old methods when the participant information is not provided (null). The patch was reviewed by Keith Chong. * What is the risk associated with this fix? I think the risk is manageable: the wst.common XML search mechanism appears to only be used by the XSD/WSDL search/refactoring function. I have run the adopter breakage scans and they came up clean. If this change is approved I will document it by notifying the committers on wtp-dev and also by adding a section on new help for old friends.
Does seem to be a major missing function, when broken. Please (continue to) test well.
Approved.
Patch committed and released for WTP 3.0 RC3 builds > v200805281546
verified in wtp3.0RC3 20080529235434 sdk
