Thanks Matthias,
I filed a bug against the RI.

Jeanne

Matthias Wessendorf wrote, On 8/25/2009 3:27 AM PT:
Hello Jeanne,

my response is inline

On Mon, Aug 24, 2009 at 8:46 PM, Jeanne
Waldman<[email protected]> wrote:
  
Hi Matthias,
My response is inline.

Matthias Wessendorf wrote, On 8/15/2009 2:02 AM PT:

On Sat, Aug 15, 2009 at 2:57 AM, Jeanne
Waldman<[email protected]> wrote:


If I change Trinidad's demo faces-config.xml file to use a bogus
default-render-kit-id, I get a NPE.

    <!-- Use the Trinidad RenderKit -->
    <default-render-kit-id>
      org.apache.myfaces.trinidad.coreBAD
    </default-render-kit-id>

I get this:

java.lang.NullPointerException
    at
com.sun.faces.renderkit.RenderKitUtils.getResponseStateManager(RenderKitUtils.java:246)
    at
com.sun.faces.lifecycle.RestoreViewPhase.isPostback(RestoreViewPhase.java:267)
    at
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:172)
    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
    at
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:104)
    Truncated. see log file for complete stacktrace


This seems to me to be a bug in
com.sun.faces.renderkit.RenderKitUtils.getResponseStateManager:

3                   renderKit = factory.getRenderKit(context, renderKitId);
  244               }
  245           }
  246           return renderKit.getResponseStateManager();

Has anyone seen this or have an opinion about this? I would have liked to
have had a log message telling me why I got a NPE at least so I didn't have
to track it down.


Question: Is the myfaces jsf-impl better here?
I don't know as I haven't done something like the above.
Sure, on first thought the bug is kinda stupid, but heck - typos can happen
:-)

So a better "warning" like a FAcesException ("there is no damn
'org.apache.myfaces.trinidad.coreBAD' renderkit")
would be way better.


I get a similar error in MyFaces.
SEVERE: An exception occurred
java.lang.NullPointerException
    at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getResponseStateManager(RendererUtils.java:1178)
    at
org.apache.myfaces.lifecycle.DefaultRestoreViewSupport.isPostback(DefaultRestoreViewSupport.java:127)
    at
org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:80)
    at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
    at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)

My use case was that someone was using an 'old' application and they let
JDeveloper migrate it. JDev doesn't touch
the default-render-kit-id and it was no longer valid, and then they got this
NPE which was impossible for them to know why from
looking at the call stack.

How should I follow up on this ?
    

I looked at Trinidad's CoreRenderKitFactory.getRenderKit()

<snip>
  public RenderKit getRenderKit(FacesContext context, String renderKitId)
  {
    if (CoreRenderKit.getId().equals(renderKitId))
    {
      renderKitId = CoreRenderKit.chooseRenderKit(context);
    }

    return _factory.getRenderKit(context, renderKitId);
  }
</snip>

the call basically delegates back to what ever has been passed in.
So, I ended up fixing the problem in MyFaces, see this revision:
http://svn.apache.org/viewvc?view=rev&revision=807541

IMO you should file a bug against the JSF RI. "Fixing" the problem in Trinidad
would basically decorate the delegate call by checking for NPE - IMO that should
be handled by the used JSF RT implementation.

-Matthias


  
Thanks!
Jeanne

-M



I suppose I could write out a warning message in Trinidad's
FacesContextFactoryImpl.java if it returns null.

Thanks,
Jeanne





    



  

Reply via email to