OK, back to my real problem...
I can't seem to use PPR in cases where I modify the component tree at
runtime. I want to use a simple dialog. Eventually, the components which
launch and handle data 'returned' from the dialog will need to be
created via java code. My first attempt resulted in the indecipherable
results below. I figured that I ought to try to use a standard
declarative version first before moving back to the code, so I followed
the dev guide placed my fields declaratively on this dynamic jsp page
and things worked somewhat better. I was able to open the dialog, but
the PPR was still borked. The ReturnEvent was still raised/heard, but
nothing was refreshed. From there I copied/pasted the jsp code into a
more static page, and everything worked fine, the dialog opens and the
appropriate fields is refreshed. What is it about modifying the
component tree at runtime which causes PPR to fail? Firebug reports no
js errors, but the second post call seems to have failed. It is
annotated with a red X, and the response never finishes 'loading...' By
contrast, on the 'static' page, the second post completes as normal
right after the return event. After that, I'll try to figure out why
building the same thing in java code fails in a different way.
JSP Code:
<tr:inputText label="test declarative"
value="#{reportCardBean.studentComment}"
partialTriggers="buttonId"/>
<tr:commandButton text="lib"
action="#{reportCardBean.onOpenCommentLibrary}"
id="buttonId"
windowWidth="500" windowHeight="500"
partialSubmit="true" useWindow="true"
returnListener="#{reportCardBean.returnedFromCommentLib}"/>
Thanks
Shane
Shane Petroff wrote:
I'm trying to test out the Trinidad dialog framework (which seems
quite simple to work with from the documentation).
What does the "Server Exception during PPR" and associated js alert mean?
The stack trace below suggests that the PPR request cannot handle
calling a particular action listener. The bean is defined in request
scope with the appropriate name, the method with the correct signature
is there. Both of these values are unchanged during the port to
Trinidad so I can guarantee that there is no naming issues. but there
is no indication of what is actually going wrong. I can pretty much be
sure that it is a 'lookup' issue of sorts since the actual method
which is supposed to be called does nothing but return a string
literal (it never actually gets called though).
Feb 29, 2008 4:12:16 PM
org.apache.myfaces.trinidadinternal.config.xmlHttp.XmlHttpConfigurator
handleError
SEVERE: Server Exception during PPR, #1
javax.servlet.ServletException: Exception while invoking expression
#{reportCardBean.onOpenCommentLibrary}
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:154)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:144)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:253)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:210)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:164)
at
org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:173)
at
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
ca.mayet.SessionTimeoutRedirectFilter.doFilter(SessionTimeoutRedirectFilter.java:78)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685)
at java.lang.Thread.run(Thread.java:619)
--
Shane
