Bugzilla – Full Text Bug Listing
| Summary: | [project explorer] Web DD loading issues during web service indexing | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Java EE Tools | Reporter: | John Lanuti <jlanuti> | ||||||
| Component: | jst.j2ee | Assignee: | Michael D. Elder <mdelder> | ||||||
| Status: | CLOSED FIXED | QA Contact: | Chuck Bridgham <cbridgha> | ||||||
| Severity: | critical | ||||||||
| Priority: | P2 | CC: | cbridgha, danberg, for.work.things, jeffliu, nagrawal, panagiotis.korros, ryman | ||||||
| Version: | 1.5 | ||||||||
| Target Milestone: | 1.5 RC5 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | PMC_approved | ||||||||
| Attachments: |
|
||||||||
|
Description
John Lanuti
*** Bug 142737 has been marked as a duplicate of this bug. *** I am unable to reproduce this error consistently in my local environment. I believe that it related to some sort of timing issue with the parsing of the package registration extensions and the first request of the J2EE schema package. The error does not appear to hinder the further operation of any function, so it does not seem that severe. In my local environment, I will normally get the error when my local firewall software blocks the request to load a schema over the network (web_2_4.xsd in this case). Running in Debug seemed to alter the timing or change the behavior enough to hide the error. I don't think I've seen this when running in Debug at all; only when running normally (either from a development image or directly). Deferring to RC5 as a fix will not be available for RC4. *** Bug 145100 has been marked as a duplicate of this bug. *** This is being seen by a number of people. *** Bug 145140 has been marked as a duplicate of this bug. *** I don't have a proposed fix yet, but here's what I believe is happening: This problem is a concurrency issue. It's taken some time to debug because the problem is intermittent, occurring somewhere between 25-40% of the time. The root of the problem comes in ResourceSetImpl.createResource(URI), where a request is received to load "META-INF/web.xml", *BEFORE* the correct Resource.Factory has been registered. The createResource() method identifies the default global resource factory (ReferencedXMIFactoryImpl) (incorrectly) to create the Web DD resource (as an instance of ReferencedXMIResourceImpl). The correct behavior would be to locate an instance of WebAppResourceFactoryImpl that would then create a WebAppResourceImpl. Because the wrong resource type is created, the Resource.load() method tries to use the EMF loading scheme (not the Translators). The resource sits quietly until load is called, when the PackageNotFoundException is thrown. It took awhile, but I've determined that the correct ResourceFactory*Registry* is registered correctly, and it doesn't look like the issue is in FileNameResourceFactory.registerLastFileSegment(), although this method is unsynchronized and open to concurrency issues. What I've found recently is that the Java initialization tooling trips the load of the org.eclipse.jst.j2ee.web plugin for the JRE contaner defined there (the WebApp Library container), on its Java initialization worker thread. The call: WebAppResourceFactory.register(WTPResourceFactoryRegistry.INSTANCE); in WebPlugin.start(BundleContext) is required to properly register the WebAppResourceFactory as the factory for "web.xml" files. The JRE container is tripping the load of org.eclipse.jst.j2ee.web plugin on its thread, and apparently before the line above is executed, the WebServicesNavigatorContentProvider's index job (on another thread) requests the "META-INF/web.xml" resource before this call to register can complete. The ResourceSetImpl.createResource() method on the WebServiceNavigatorContentProvider's thread finds no Resource.Factory registered for the "web.xml" segment, and consequently chooses ReferencedXMIResourceFactory as the default. The wrong resource is created, and silently the stage is set for the PackageNotFoundException later on. The only worthy fix here that I can see is the addition of an internal extension point that would declare: *the filename short segment (e.g. "web.xml") *the fully qualified classname of the Resource.Factory for the short segment. Then the WTPModulesResourceFactory would be re-implemented to take advantage of this extension point, instead of relying on plugin startup to register the file-name, resource factory pairs. "WTPResourceFactoryRegistry", not "WTPModulesResourceFactory". After discussing these issues with Michael, we have determined that the registry scheme that "assumes" startup order is flawed, and a more direct registration using extension points is required. The ResourceFactoryRegistry (WTPResourceFactoryRegistry) will use an extension point mechanism that will be checked if no factory has been registered, thus eliminating any "timing" issues of assumed plugin startup order. Michael will attach a patch when available. Created attachment 43635 [details]
Patches several plugins to drive registration through an extension point
The patch applies to the following plugins:
org.eclipse.jst.j2ee
org.eclipse.jst.j2ee.core
org.eclipse.jst.j2ee.ejb
org.eclipse.jst.j2ee.web
org.eclipse.jst.j2ee.webservice
org.eclipse.wst.common.emf
org.eclipse.wst.common.modulecore
The patch refactors FileNameResourceFactoryRegistry in org.eclipse.wst.common.emf to be a little more robust in tracking the association between short names and Resource.Factory's.
A new extension point (for internal use only) is addded to org.eclipse.wst.common.modulecore that declares a registration for short-name to resource factory pairs. The WTPResourceFactoryRegistry subclass of FileNameResourceFactory is updated to parse this extension point and create mappings in FileNameResourceFactoryRegistry, as if the old plugin.start() semantics were used.
WTPResourceFactoryRegistry can also log invalid usages for those that are still calling FileNameResourceFactoryRegister.registerLastFileName() directly, rather than through the extension point.
The package that declares FileNameResourceFactoryRegistry in org.eclipse.wst.common.emf was added as a friend package for the org.eclipse.wst.common.modulecore plugin. The split here had to be made for various reasons, but it was required.
The Descriptor classes (that map short-names to Resource.Factory's) and the ext pt registry reader are coded defensively, so there shouldn't be alot of risk from extensions.
The remaining plugins required changes to (1) define no-arg constructors for the existing Resource.Factory subclasses and (2) declare the org.eclipse.wst.common.modulecore.resourceFactories extensions to take advantage of the new changes, and (3) remove the programmatic calls from Plugin.start() methods.
WTPResourceFactoryRegistry will still support programmatic registration for any clients that cannot port, and supports a compile-time flag to turn on warning messages.
Added to PMC for approval.... I was reproducing this bug reliably in I200606070737. In order to do some testing, I built and applied this patch. An FYI to save a build cycle, Thread.getStackTrace(), used by WTPResourceFactoryRegistry, is new for 1.5. I substituted "(new Throwable()).getStackTrace()" for "Thread.currentThread().getStackTrace()". As expected, with the patch I'm no longer reproducing the problem. +1 for WTP 1.5 RC5. Testing seems to verify the fix. +1 1.5 It might be wise (as comment 12 points out) to remove the "Thread.currentThread().getStackTrace() line used to log warnings, if the build is not JRE 1.5 compliant. This was used to provide better context to locate places where programmatic registration was still used. Removing the logging logic will not affect the patch. Released for WTP 1.5 RC5 060706 driver. Created attachment 43835 [details]
port back to 1.4 compliance
Build Breaker #8 ...
who did not take Michael's advice?
thread.getStackTrace()
and
string.contains
are not part of JRE 1.4!
You can blame me. I use 1.4 compliance compiler settings and did not have any errors in my workspace, so that gave me false assurance it was resolved in the patch already. Thanks David for that catch. Bonus round! Who can spot the potential API breakage? Adopter usage reports show this class is being used by three IBM adopters and one BEA adopter. Running the API scan on the new class doesn't show any problems, but I don't see any indication that it was run either. However, making the constructor private broke at least one of the IBM adopters using this class. Just a reminder to developers and the PMC that reviewed this change to check for breakage and be very wary of making changes like this late in the cycle. I'll follow up with Jeffrey to figure out why the scan tool isn't working. The problem is caused by out of date usage reports. After 1.5, I'll get in touch with the adopters regarding how to provide usage reports more often. Verified on 061606. |