Details
Description
We've implemented our own Message Renderer and Messages Renderer, so that the output will always be wrapped in a div, to better work with our dom differencing. As part of the MyFaces 2 integration in ICE-5868 we switched from using the faces-context.xml to override the renderers to doing it programmatically, since our renderers override the Mojarra ones, and we can't use them with MyFaces. This has the side-effect of thwarting applications from overriding the renderers themselves.
The quickest fix would be to change the renderkit code that checks to see if we should override the renderers to do an exact class name check for the Mojarra renderers, so that we don't stomp on 3rd party renderers.
The quickest fix would be to change the renderkit code that checks to see if we should override the renderers to do an exact class name check for the Mojarra renderers, so that we don't stomp on 3rd party renderers.
Changed in DOMRenderKit from checking component family and renderer type ids ("javax.faces.Message") to checking renderer class name ("com.sun.faces.renderkit.html_basic.MessageRenderer".), i.e., only override with our renderer class ("org.icefaces.impl.renderkit.html_basic.MessageRenderer") when registered rendderer class is Mojarra class.
Side effect: with MyFaces, the class name is "org.apache.myfaces.renderkit.html.HtmlMessageRenderer", so our override renderer class can't take over anymore.
Same with MessagesRenderer.
User-registered renderer works now provided user registers the renderer in the proper order mentioned above. See screenshot 2.
Revision: 24081
Modified : /icefaces2/trunk/icefaces/core/src/main/java/org/icefaces/impl/renderkit/DOMRenderKit.java