Community
Participate
Working Groups
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.
Created attachment 171590 [details] Adds sorting of delegates in AbstractDelegatingFactory so that non-OSS (adopter) delegates are always accessed first.
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.
We will fix this issue in the first maintenance release.
Patch applied to HEAD (3.2.2).
