2010-10-19 12:40:32,271:ERROR Problem encountered during View.servePage - com.icesoft.faces.context.View java.lang.IncompatibleClassChangeError: Implementing class at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:983) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1501) at za.co.enerweb.nampower.report.hibernate.HibernateSessionFactory.(HibernateSessionFactory.java:60)
Showing posts with label Icefaces. Show all posts
Showing posts with label Icefaces. Show all posts
Tuesday, 19 October 2010
IncompatibleClassChangeError: Implementing class
In my case this was caused by incompatible versions of hibernate in the classpath...
Wednesday, 23 December 2009
Why can't icefaces give proper error messages? II
After days of searching and experimentation it seems that its not possible to dynamically import
a .jspx file into another (one which is loaded from a jar, and the src location is supplied by the backing bean).
I'm trying to embed iframes now, but as soon as the iframes render, icefaces freezes up and does not send any events again. The only clue was this javascript error:
After searching and a hunch that concurrently loading jspx pages breaks icefaces, I looked at the portlet sample
(ICEfaces-1.8.2-src/icefaces/samples/portlet/location/web/WEB-INF/web.xml).
I found that if I include the following in my web.xml, it works! Hurray!
This makes sense because I want to load several iceface pages in iframes in my main page.
a .jspx file into another (one which is loaded from a jar, and the src location is supplied by the backing bean).
I'm trying to embed iframes now, but as soon as the iframes render, icefaces freezes up and does not send any events again. The only clue was this javascript error:
Error: no element found
Source File: http://localhost:17080/EbrWeb/block/receive-updated-views
Line: 1
After searching and a hunch that concurrently loading jspx pages breaks icefaces, I looked at the portlet sample
(ICEfaces-1.8.2-src/icefaces/samples/portlet/location/web/WEB-INF/web.xml).
I found that if I include the following in my web.xml, it works! Hurray!
<context-param>
<param-name>com.icesoft.faces.concurrentDOMViews</param-name>
<param-value>true</param-value>
</context-param>
This makes sense because I want to load several iceface pages in iframes in my main page.
Thursday, 10 December 2009
Why can't icefaces give proper error messages?
SEVERE: StandardWrapperValve[Persistent Faces Servlet]: PWC1406: Servlet.service() for servlet Persistent Faces Servlet threw exception
java.lang.Exception: javax.faces.FacesException: Problem in renderResponse: null
was trying to tell me:
<ice:tree> needed to be encapsulated inside an <ice:form>.
http://seamframework.org/Community/ProblemWithIceTree#comment101040
Tuesday, 13 October 2009
(Ice)faces hates me and Richard
After Richard Kolb and I have struggled with this for days, I finally cracked it.
We defined some dropdowns, and radio buttons in icefaces eg:
but when a new item was selected nothing happened, we just got this VERY cryptic log entry e.g:
After hours of (debugging, guessing, googling, repeat) loops,
I finally found this link which explains it a number of times:
http://www.icefaces.org/JForum/posts/list/7965.page
Faces or icefaces does not automagically serialise or cache objects when sending it to the browser!
It converts to/from Strings if it can
and tries to waste as much of your time as possible if it can't!
So my fix was setting the selectItem's value to our DB Id in stead of the object,
using the Id property for the SelectOne value.
Then on partial submit when the setter gets called,
we have to iterate through the cached list to find the one matching the Id to set the real property.
We defined some dropdowns, and radio buttons in icefaces eg:
<ice:selectOneRadio id="reportColumnIndexRadio"
value="#{scratchPad.reportColumnIndex}"
partialSubmit="true"
layout="pageDirection">
<f:selectItems
value="#{scratchPad.reportColumnIndexSelectItemList}" />
</ice:selectOneRadio>
<ice:selectOneMenu id="reportColumnIndex"
value="#{scratchPad.reportColumnIndex}"
partialSubmit="true">
<f:selectItems
value="#{scratchPad.reportColumnIndexSelectItemList}" />
</ice:selectOneMenu>
but when a new item was selected nothing happened, we just got this VERY cryptic log entry e.g:
sourceId=reportEditorForm:j_id14[severity=(ERROR 2),
summary=(reportEditorForm:j_id14:
An error occurred when processing your submitted information. ),
detail=(reportEditorForm:j_id14:
An error occurred when processing your submitted information. )]
After hours of (debugging, guessing, googling, repeat) loops,
I finally found this link which explains it a number of times:
http://www.icefaces.org/JForum/posts/list/7965.page
Faces or icefaces does not automagically serialise or cache objects when sending it to the browser!
It converts to/from Strings if it can
and tries to waste as much of your time as possible if it can't!
So my fix was setting the selectItem's value to our DB Id in stead of the object,
using the Id property for the SelectOne value.
Then on partial submit when the setter gets called,
we have to iterate through the cached list to find the one matching the Id to set the real property.
<ice:selectOneMenu id="reportColumnIndex"
value="#{scratchPad.reportColumnIndexId}"
partialSubmit="true">
<f:selectItems
value="#{scratchPad.reportColumnIndexSelectItemList}" />
</ice:selectOneMenu>
Subscribe to:
Posts (Atom)