Hi Adam
I just updated to the 1.2 branch but the error is still there:
java.lang.IllegalStateException: No RenderingContext
at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:156)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin(UIXComponentBase.java:704)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1267)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:757)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:890)
at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:571)
at
javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:178)
at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:171)
at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
Since the code is changed and I'm short on time today, I wasn't able
to exactly find out whats going on. But I suspect its due to the
missing CoreRenderKit.encodeBegin() call, which will not happen if
trinidad is not used as the default render kit. The problem should
basically be the same as described in the first mail.
Regards,
Stefan
On 2/16/07, Adam Winer <[EMAIL PROTECTED]> wrote:
Stefan,
We have a JSF 1.2 branch of Trinidad which is well tested,
and contains (nearly) the latest code.
http://svn.apache.org/repos/asf/incubator/adffaces/branches/faces-1_2-070201/
The only bad news is that you currently have to build
it yourself - we don't have an automated build going for
this branch.
(FYI, we rebranch every once in awhile, and the URL changes
when we do.)
-- Adam
On 2/15/07, Stefan Podkowinski <[EMAIL PROTECTED]> wrote:
> Hello
>
> Currently it does not seem to be possible to use trinidad with jsf1.2
> ri and facelets and not having trinidad declared as default rendering
> kit.
>
> Removing
>
>
<default-render-kit-id>org.apache.myfaces.trinidad.core</default-render-kit-id>
>
> from faces-config.xml and adding the render kit declaration to the view root
>
> <f:view ... renderKitId="org.apache.myfaces.trinidad.core">
>
> will break the view handling process with the following error:
>
> java.lang.IllegalStateException: No RenderingContext
> at
org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:159)
> at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin(UIXComponentBase.java:668)
> at
org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1209)
> at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:721)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:890)
> at
com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:571)
> at
org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:182)
> at
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
>
>
>
> After doing some debuging, I came to the conclusion that this must be
> due to the trinidad ViewHandlerImpl.renderView() method
> implementation. The problem is the way the ViewHandlerImpl wraps the
> delegate, but needs to setup the RenderingContext before the delegate
> is executed. Creating the RenderingContext is currently done by
> CoreRenderKit.encodeBegin(). But this won't never happen in this case,
> because facelets did not parse the page including the <f:view
> renderKitId..> element yet, so we don't know which render kit to use
> before calling the facelets delegate!
>
> So here's whats happening in ViewHandlerImpl:
> 160: ExtendedRenderKitService cannot be found because trinidad is not
> the default anymore
> 172: CoreRenderKit will not be called to setup RenderingContext (thread local)
> 182: delegation to FaceletViewHandler
> afterwards
>
org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:159)
> fails on non initialized thread local.
>
> What do you think? Is there a chance to reimplement
> ViewHandlerImpl.renderView() so this problem could be resolved? Any
> possible side effects?
>
> Thanks,
> Stefan
>
