h:commandLink NullPointerException

[Ally Cavs]

Hi Guys

Anytime I use a h:commandLink and h:commandButton I get the following stack trace:

java.lang.NullPointerException
at javax.faces.component.UIComponentBase.getRenderer(UIComponentBase.java:1402)
at javax.faces.component.UIComponentBase.decode(UIComponentBase.java:785)
at org.ajax4jsf.component.AjaxViewRoot$1.invokeRoot(AjaxViewRoot.java:392)
at org.ajax4jsf.component.AjaxViewRoot.processPhase(AjaxViewRoot.java:226)
at org.ajax4jsf.component.AjaxViewRoot.processDecodes(AjaxViewRoot.java:405)
at com.sun.faces.lifecycle.ApplyRequestValuesPhase.execute(ApplyRequestValuesPhase.java:78)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:281)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:655)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:619)


I am using glassfish 3 which has JSF 2 bundled in and this richfaces jar in the pom.xml of my maven project

<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-ui</artifactId>
<version>3.2.1.GA</version>
</dependency>

Any light on this is much appreciated. this is the closest issue I can find on the net but Im not sure if its the same issue.
http://www.crazysquirrel.com/computing/java/jsf/command-links.jspx

Alan

[Tim Holloway]

I really wish people would include dates on their published wisdom. Otherwise it's impossible to tell whether what they're saying applies to modern-day problems or to something that was fixed 5 years ago. In any event, Señor Squirrel is still in the "why can't JSF work just like JSPs?" stage.

One of the most frustrating things you can get in JSF is this kind of NullPointerException. You think it's related to the commandLink, but there's a high probability that in fact what it really is is a consequence of the train of events that firing the commandLink set into motion. For example, not having a proper datamodel on one of the controls on the subsequent View can give you this. And good luck trying to figure out which one it is!

What I end up having to do in cases like this is set a debugger breakpoint and walk my way up the stack. Just to make things even MORE annoying, setting a breakpoint on NullPointerException will swiftly inform you that a lot of people will throw and catch NPE's casually as part of their normal logic flow instead of using mechanisms that would require more work but be less dire.

Once you've managed to park on the NPE in getRenderer, start looking at stack frames. The variables that will tell you what you need to know are the control ID and the EL expression representing the missing/misspelled property reference. Unfortunately, I can't tell you actual names or locations, so it take a certain amount of digging.

This, by the way, is one reason why it's good practice putting IDs on your controls. If you find the offending control and its ID is "j_145", you really don't know much more than you did originally.

[Ally Cavs]

I would like to debug but I do not know what version of the Mojarra jar i have. Im using glass fish 3 and i searched all folders for Mojarra. Nothing came up. So where ever its pulling the UIComponentBase class from, I do not know. I need to find the correct version first and then the source code for it.

I think this may be class path issue though or something to that effect. I have tried submitting a simple for m like this and i get the stack trace. So i do not believ it to be a null component issue:

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<h:html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:p="http://primefaces.prime.com.tr/ui">
    <h:head>
</h:head>

    <h:body>
       <h:form>

       <h:commandLink value="HTML Submit" action="#{primeFaceBean.submit}"/>
        <h:commandButton value="HTML Submit" action="#{primeFaceBean.submit}" type="submit"/>
        <p:commandButton value="PrimeFace" action="#{primeFaceBean.submit}" ajax="false" type="submit"/>
      </h:form>
    </h:body>
</h:html>  

[Tim Holloway]

You don't need the source code to get variables displayed in a stack browse in an IDE debugger. For these particular classes, seeing the source code wouldn't even help that much, actually.

If you're using a recent version of GlassFish, the JSF core classes (jsf-impl.jar) are part of GlassFish itself. So your WAR needs to have jsf-api.jar, but not jsf-impl.jar. Tomcat would require both.

If you're getting the problem I'm suspecting, the actual error may not be on the page you think it is.

[Ally Cavs]

ok guys

if i remove this from my pom the stack trace disappears and things work as expected

<dependency>
<groupId>org.richfaces.ui</groupId>
<artifactId>richfaces-ui</artifactId>
<version>3.2.1.GA</version>
</dependency>


Everything works as expected but I want this lib as I want to use the ajax4jsf tag library which is bundled in this jar.
So it is a classpath problem. Any ideas?

Alan

[Tim Holloway]

Here's how I do it:

		<dependency>
			<groupId>org.richfaces.framework</groupId>
			<artifactId>richfaces-api</artifactId>
			<version>3.3.3.Final</version>
			<scope>compile</scope>
		</dependency>
		<dependency>
			<groupId>org.richfaces.framework</groupId>
			<artifactId>richfaces-impl-jsf2</artifactId>
			<version>3.3.3.Final</version>
			<scope>compile</scope>
		</dependency>
		<dependency>
			<groupId>org.richfaces.ui</groupId>
			<artifactId>richfaces-ui</artifactId>
			<version>3.3.3.Final</version>
			<scope>compile</scope>
		</dependency>

I also have to put in some slf4j stuff, but that may just be because I'm also using Hibernate and log4j.