Bug 316385

Summary: Change to taglib resolver construction is breaking OEPE
Product: [WebTools] Java Server Faces Reporter: Cameron Bateman <cameron.bateman>
Component: CoreAssignee: Cameron Bateman <cameron.bateman>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P1 CC: david_williams, ian.trimble, raghunathan.srinivasan, thatnitind, yurykats
Version: 3.2   
Target Milestone: 3.2.2   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
Adds sorting of delegates in AbstractDelegatingFactory so that non-OSS (adopter) delegates are always accessed first. none

Description Cameron Bateman CLA 2010-06-09 17:18:13 EDT
We changed the way that the taglib resolver is constructed so that it returns a ViewBasedTaglibResolver instead of the old DefaultTaglibResolver.  As a result of this, we unintentionally tied resolver construction to the lifecycle of the JSF core plugin and the JSF facet.  

We have just discovered that this causes some critical loss of service in our OEPE adopter product.  We need to change the way these factories are selected so that we can guarantee that they are loaded and executed in a certain order.
Comment 1 Cameron Bateman CLA 2010-06-09 19:26:29 EDT
Created attachment 171590 [details]
Adds sorting of delegates in AbstractDelegatingFactory so that non-OSS (adopter) delegates are always accessed first.
Comment 2 David Williams CLA 2010-06-09 22:06:33 EDT
What's OSS stand for? Open Source Software? 

Are you actually expecting multiple factories to be provided, and you "handle" them all? Or, more like one from JSF Open Source, and one from an adopter? 


What's the bug number for "changed the way the taglib resolver is constructed"? Was that basically an API breaking change? Or ... probably not, I'm just trying to understand ... why does that change "... we unintentionally tied resolver construction to the lifecycle of the JSF core plugin and the JSF facet". And how does the sort beat that problem? Just force them all to be loaded? [You can tell, I don't understand enough to ask the right questions ... but that's why I'm asking, to understand]. 

Lastly, I guess you don't need me to tell you that examining "package names" (as you do in the patch) sure looks like a hack. :) A clever one, I'll admit ... but, doesn't really seem like a normal "order and select best factory" mechanism. Do you see that as the final, real fix? Or a temporary work around and another mechanism in place next (future) release. 

Thanks in advance for the education.
Comment 3 Raghunathan Srinivasan CLA 2010-06-10 13:56:50 EDT
We will fix this issue in the first maintenance release.
Comment 4 Cameron Bateman CLA 2010-08-18 20:22:31 EDT
Patch applied to HEAD (3.2.2).