Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #345220 +++ Build Identifier: 2.1.0, 2.1.1, 3.0.0.M03 When loading resources from other bundles using thread context class loader's getResources() method, duplicate results would be given. For example, running the following line in a servlet results in 2 faces-config.xml files to be returned: Thread.currentThread().getContextClassLoader().getResources("META-INF/faces-config.xml"); Also, not sure if this is a bug, when trying to reproduce this bug, I noticed that getResources() can only load resources from a bundle that has classes. Any bundle without classes, but only the resources, would result in the bundle being ignored by getResources(). This bug may result in duplicate phase listeners to be registered in a JSF environment. As such, this bug was originally filed to MyFaces (https://issues.apache.org/jira/browse/MYFACES-3055). Reproducible: Always Steps to Reproduce: 1. Set up a bundle that has an empty class and a resource file. 2. Make sure the package of the empty class is exported. 3. Set up a web bundle that imports the package exported in step 2. 4. Create a servlet and run Thread.currentThread().getContextClassLoader().getResources("path to the resource file"). Notice that 2 entries would be returned.
I identified that org.eclipse.gemini.web.tomcat.internal.loading.ChainedClassLoader.getResources(String) in some cases may return one and the same resource presented by more than one URL. We will introduce functionality to remove the duplicated URLs.
Created attachment 196122 [details] Patch Could you please review the patch Thanks
Comment on attachment 196122 [details] Patch The fix looks ok except I was a little puzzled why you chose url.getFile() to produce the String map key. Presumably this has some advantage over simply using the url. May be worth adding a comment.
(In reply to comment #3) > Comment on attachment 196122 [details] > Patch > The fix looks ok except I was a little puzzled why you chose url.getFile() to > produce the String map key. Presumably this has some advantage over simply > using the url. May be worth adding a comment. I didn't want to use URL.equals() because of the following in the java doc of the method: "Since hosts comparison requires name resolution, this operation is a blocking operation. Note: The defined behavior for equals is known to be inconsistent with virtual hosting in HTTP." I chose toFile() instead of toString(), because getFile() just returns the 'file' field that is initialized during URL construction. Method toString() does a lot of calculations.
Commit Id: 927f4b0b7875c002656d40c7b0c35f16038dd432
