Hi, That did the trick, thanks a lot!
Regards, Hampus On Wed, 30 Nov 2011 15:55:44 -0500, Leonardo Uribe <lu4...@gmail.com> wrote: > 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 >> >>
