Messages posted by: ted.goddard  XML
Profile for ted.goddard -> Messages posted by ted.goddard [693] Go to Page: Previous  1, 2, 3 ... 44 , 45, 46, 47 Next 
Author Message
Have you had luck with a UTF-8 version of the page? ICEfaces supports UTF-8 to some degree.
We have tested the sample application and cannot reproduce the ClassCastException. However, the navigation rules seem to be behaving strangely.

We are running with JDK 1.5.0_05, Tomcat 5.0.28 and RedHat Linux.

We took the following steps:

1. Connect to http://localhost:8080/tree/
2. Press "Login" button
3. Click on tree "+" to expand

With MyFaces the tree does not expand, the page returns to login.iface.
With the Sun JSF implementation, the tree does expand.
(With MyFaces the tree works from http://localhost:8080/tree/main.iface)

Is this the root problem of the bug?
There could be a conflict introduced by the Faces Servlet mapping for *.jspx, but this would likely produce a parsing exception if the conflict occurred.

To diagnose the

java.lang.ClassCastException: org.apache.html.dom.HTMLTableSectionElementImpl

I believe we need a standalone test case. Would it be possible to provide a complete test case that produces the exception?
Please send a test application to product.support@icesoft.com
We have tested the supplied code and find that it runs without exceptions.

However, the supplied code does not seem to match the reported problem (perhaps it's from a different page, or the navigation rules are causing an unexpected page to be loaded?).

For instance, the supplied code does not contain CommandLink or BorderLayout; can you confirm that the supplied code exhibits the reported problem?
From the stack trace, the most likely cause is a bug in the ICEfaces CommandLinkRenderer. Please provide sample pages that produce the exception (either upload them to this forum or send them to product.support@icesoft.com).
This is due to a bug in MyFaces: the MyFaces Lifecycle is applying a mapping to the ViewID when that mapping should actually be performed by the ViewHandler. To get around this, you may be able to use the following context parameter

   <param-name>javax.faces.DEFAULT_SUFFIX </param-name>
       By default, MyFaces automatically converts certain extensions to
       .jsp. For ICEfaces, our own PersistentFacesServlet is triggered
       by the .jspx extension.

Further documentation is available here:

This form of JSP inclusion is intended to work with


(the idea is to add ICEfaces content to an existing JSP application).

Have you tried the above link? If it fails similarly, you may need to remove a servlet mapping that sends *.jsp to the PersistentFacesServlet.

You may also wish to try generating a .war file and deploying to an external application server such as tomcat.
We have confirmed that the stack trace you are seeing is present in ICEfaces 0.3-Alpha, but is fixed in ICEfaces-0.3.1-Alpha. Please update to the latest version of ICEfaces.

Also, be sure to stop and restart your server within Eclipse to ensure that the desired code is running.
If you have ICEfaces pages that need to statically (at parse time) include other ICEfaces pages, you should use something like the following

<jsp:directive.include file="./inc/content/splashTableComponents.jspx" />

(See the component-showcase for example code.)

Does this match what you are trying to do?
Pages ending with .jsp are pre-processed before being sent to ICEfaces. Essentially two conversions are performed: non-XHTML (things like <br> and <p> tags) is converted to XHTML and JSP page syntax is converted to JSP document syntax.

If you wish to work in JSP Page syntax, use .jsp (but be aware that it will be transformed by ICEfaces). If you wish to use JSP Document syntax, use .jspx.

Transformation is performed after inclusion, so when static includes are used, the parent page type (.jsp or .jspx) determines wether any tag conversion is done. Therefore, it is best not to mix .jspx and .jsp within the same project.
Since your files are JSP pages rather than JSP documents, JSP page syntax must be used:

<%@ include file="/pages/header.jsp" %>

(It appears that ICEfaces requires a fully-qualified path. A future release of ICEfaces will correct this.)
JSP Documents are the preferred format for ICEfaces and must have the .jspx extension. Within a single project, all ICEfaces files should be .jspx or all ICEfaces files should be .jsp. It is not recommended that they be mixed:

.jspx including .jsp: complications arise due to .jsp not being converted to XHTML
.jsp including .jspx: complications arise due to XHTML conversion of the .jspx already in XHTML format
Here's a workaround that should actually work; add a value binding expression to the outputDeclaration Tag to force it to be executed each time (the root cause of this bug is that the ICEfaces framework is marking the component as "static" and only executing it once). Note the isDynamic binding below with a simple expression below:

<ice:outputDeclaration doctypeRoot="HTML" doctypePublic="-//W3C//DTD HTML 4.01 Transitional//EN" doctypeSystem="http://www.w3.org/TR/html4/loose.dtd" isDynamic="#{}" />

It sounds as if the concurrentDOMViews setting is causing the AJAX connection to be partially lost; we have recently encountered this bug in another application and plan to fix it in an upcoming release. In the meantime, I suggest instead using the above workaround to maintain the DOCTYPE.
Does the tutorial timezone5/includeTest.jsp work correctly?

If not, are there any messages on the tomcat console?
Profile for ted.goddard -> Messages posted by ted.goddard [693] Go to Page: Previous  1, 2, 3 ... 44 , 45, 46, 47 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team