Hi
MyFaces in that part has some junit test cases for config ordering. If
portletfacesbridge has:
<ordering>
<before>
<others/>
</before>
</ordering>
That means it is the first application configuration resource to be
processed, so if it wraps the default HTML_BASIC renderkit (it does)
and icefaces or primefaces do the same, the wrapper on top will be the
last processed configuration resource. So the behavior described is
correct. The solution could be create another faces-config.xml inside
portletfacesbrigde jar file (renderkit.faces-config.xml for example),
and add this processing instruction:
<ordering>
<after>
<others/>
</after>
</ordering>
That will work.
regards,
Leonardo Uribe
2011/11/29 Hampus Wingren <hampus.wing...@bredband.net>:
> So I saw that icefaces-ace do not support portlets yet but I experience
> the same problem with primefaces 3.0M4
>
> Regards,
> Hampus
>
>
>
> On Mon, 28 Nov 2011 12:11:28 +0100, Hampus Wingren
> <hampus.wing...@bredband.net> wrote:
>> Hi,
>>
>> Do you know if there are any problems with the implementation
>> of ordering of faces-config´s in myfaces? I´m running myfaces 2.1.3,
>> portlet 286, icefaces and portletfacesbridge and have some problems with
>> the order of renderers.
>>
>> The portletfacesbridge has one head renderer
>> and one body renderer and they state in their faces-config an order of
>> before others but as soon as I add icefaces-ace which provide its own
>> head renderer (but no ordering), I end up with icefaces-ace doing the
>> head rendering.
>>
>> Shouldn´t the portletfacesbridge renderer get a higher
>> priority in this case?
>>
>> Regards,
>>
>> Hampus
>
>
