ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

If you don't run the render call in its own thread, there is a high risk of deadlock and other nasty concurrency issues - exactly the types of things we aim to avoid by providing the RenderManager. I'd strongly suggest taking a look at it.

However, to get your example going using the state.render() call, I'd suggest creating an implementation of Runnable and sticking the render call inside the run method and whenever you need to render, simply run it in a Thread.

Deryk

The line regarding where to find the cached tld stuff didn't paste in too well. It should have read:

[jboss-install-dir]/server/[server-config]/work/jboss.web/localhost/[application]/

I was unable to replicate the exact problem you were having but the previous information I provided still seems to be accurate for this version of JBoss.

A couple of questions:

1) When you refer to a the "manifest reference mechanism", what do you mean? Are you placing the icefaces.jar somewhere other than WEB-INF/lib then refering to it via some other manifest entry? If so, this will likely cause a problem with the ICEfaces tld scanning. For the current release, the icefaces.jar should go in the WEB-INF/lib directory of your application.

2) The error message "Class com.icesoft.faces.application.D2DViewHandler is no javax.faces.application.ViewHandler" is a bit of a puzzler but may be explained if there is more than one JSF implementation available (Sun RI and MyFaces). In that case, see my previous post.

Deryk

It's tough to tell from the code snippet whether or not the state is indeed null or not. I'm not sure which release you are using but we recommend using the Rendering API (available since the beta release) rather than attempting to use the lower level PersistentFacesState.render method directly. Check the Developer's Guide for more detailed information. As a quick summary:

1) Ensure that a reference to the PersistentFacesState was properly retrieved in the constructor of your managed session bean. If not, then a NullPointerException may occur.

2) Ensure you do the rendering in a separate thread. If not, then you could potentially have problems. Again, we recommend you use the RenderManager if possible but at a minimum, the state.render() call should be done in a separate thread.

I'm also not sure what example code you are referring to. Please indicate which release of ICEfaces you are using. The Community Edition 1.0 release is now available and you should upgrade if possible.

All or our examples should refer to the Rendering API. If they don't we'll correct it.

Deryk

The group renderers are not currently designed to be re-used in this way. I'll make a note to discuss adding the feature in a future release.

As a work-around in the meantime, I'd recommend creating two renderers with different names and different intervals. Something like this for example:

...
private IntervalRenderer shortClock;
private IntervalRenderer longClock;
private IntervalRenderer activeClock;
...
if( renderManager != null ){
if( shortClock == null ){
shortClock = renderManager.getIntervalRenderer("shortClock");
shortClock.setInterval(1000);
shortClock.requestRender();
}
if( longClock == null ){
longClock = renderManager.getIntervalRenderer("longClock");
longClock.setInterval(60000);
longClock.requestRender();
}
}
activeClock = shortClock;
activeClock.add(this);
...

Then when you need to change, simply remove the Renderable from one renderer to the other. Something like this:

private void switchRenderer(){
activeClock.remove(this);
if( activeClock == shortClock ){
activeClock = longClock;
} else {
activeClock = shortClock;
}
activeClock.add(this);
}

I realize that this may not be ideal but it should do what you need it to do.

Deryk

I'm downloading 4.0.4 as I write this but maybe I can offer some insight before I test it out.

JBoss comes with MyFaces pre-installed so you have two options for your JSF/ICEfaces applications:

1) Do not include any JSF implementation jars (either MyFaces or Sun RI) with your application. Simply rely on the MyFaces libs that are intalled with JBoss. Make sure that you have your web.xml configured correctly for MyFaces (e.g. you must include the org.apache.myfaces.webapp.StartupServletContextListener listener). The tutorial samples come with web.xml files for both Sun RI and MyFaces so you can look there for other entries of interest.

2) Remove the MyFaces implementation from your JBoss server configuration. If you do this, then you must include the JSF implementation (either Sun RI or MyFaces) with your application.

JBoss has a Wiki entry that discusses this in bit more detail:

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossWithIntegratedMyFaces

One other problem that I encountered was that I also had to make sure that I removed any cached tld entries for my applications. If these were lying around, they could potentially cause a problem. They can be found in:

<jboss-root>/server/<config>/work/jboss.web/localhost/<app>/

Hopefully this helps. I'll check out JBoss 4.0.4 in the meantime to see if there is anything else causing problems.

Deryk

Good question and there are a number of different factors to consider in providing a useful answer. The main factor is the characteristics of your application and what you are trying to achieve with the cluster (performance, fault tolerance, etc.). I'll provide what advice I can and if you have more specific queries, please don't hesitate to follow up.

First of all, it should be technically feasible to deploy a Community Edition ICEfaces application on a cluster (I can honestly say we haven't tried doing it with Tomcat yet). The key consideration for clustering ICEfaces applications is to allow for session affinity ("stickiness"). Session replication may also be considered for cleaner failover but would depend on the characteristics of your particular application. Session replication can be expensive and it may be easier just to have any active users on a failed node simply "relogin" and get a new session on a different node.

The main advantages of using the Enterprise Edition are:

1) Async Server - The Async Server allows for much more efficient thread usage on the application server. If your application is purely synchronous (no server-initiated rendering), then this may not be an issue. If you are relying on server-initiated rendering, then thread consumption may prevent you from running many concurrent users on a single node.

2) Advanced Connection Management - Allows for control and handling of a client connection to the server. Depending on how live and dynamic your application is, this can provide a much nicer user experience.

3) Clustered Rendering (coming in a later release) - This won't be in the upcoming release but we are working on providing server-initiated rendering that spans across nodes in a cluster. For example, all the users in a chat room could be kept in sync no matter what node they resided on. This emphasizes a different use for the cluster than just fault-tolerance.

Again, the characteristics of your application will determine what functionality your require. I'd be interested to know what your application does and how the cluster is being utilized.

Deryk

I'm sorry that you're having difficulty getting the demos to work in other browsers. We don't officially support Opera at this point but I did manage to get it working. I'll mention it to the Product Manager and see if we can get official Opera support added to the product roadmap.

I can say with all confidence that ICEfaces does work with Firefox. It is officially supported and has been extensively tested. It's used regularly by the development team so I'm surprised that it is not working properly. However, there are a few things you can try so we can help narrow down the issue.

1) Check the Tomcat log file (<tomcat>/logs/catalina.out) to see if there are any obvious errors being dumped out while you work with the application. If you find something, you can either copy it to the forum or send it to product.support@icesoft.com.

2) Ensure that JavaScript is turned on in all the browsers. We rely heavily on JavaScript. Cookies should be enabled as well.

3) We provide a JavaScript debugging window that you can turn on by pressing SHIFT-CTRL-T (if you have popups blocked, you'll want to configure your browser to allow this). It should show a regular "heartbeat" every 10 seconds or so. It'll look something like this:

10:23:42 info [window.async-connection.heartbeat] : ping
10:23:42 debug [window.ajax] : [64108] : send asynchronous GET
10:23:42 info [window.async-connection.heartbeat] : pong
10:23:42 debug [window.async-connection] : closing previous connection...
10:23:42 debug [window.ajax] : [2576298] : connection closed
10:23:42 debug [window.async-connection] : connect...
10:23:42 debug [window.ajax] : [4228656] : send asynchronous GET

You should also see some indication of XmlHttpRequest traffic in the JavaScript log as you use the demo. If you are not getting a heartbeat or other AJAX communications, then you'll likely see the behaviour similar to what you've described.

Deryk

The messages you are seeing in the console are a known issue and should not effect the general functioning of the demos using Firefox 1.5.0.2 (or Opera 9 beta).

Have you tried the the online demos with Internet Explorer or Safari? These browsers are supported as well and if you cannot properly view the online demos with them, then that might provide valuable information for troubleshooting the problem you are having.

I'm not sure what you mean by "submitting the form". Are you still referring to the online demos? The various components (like the tree) should submit form data when you click on a node and shouldn't require any special action on your part.

Deryk

Our next release is 1.0 and will be released before JavaOne which starts on May 15th, 2006. Portlets will not be supported in that release. Past that, the road map is a bit more fluid and will depend on customer feedback. What kind of schedule do you have for you project? At this point, depending on the characteristics of your project, it is possible to influence the roadmap.

Deryk

Oops, I guess JavaOne officially starts on May 16th. By the way, if you our your company is attending, we'll have a booth there. Unfortunately, I won't be able to attend bure you can talk to several of our engineers and product people. It would be a good time to pressure us for portlet support.

Deryk

Another thing to try besides other browsers, is to run a local copy of the component-showcase on your own machine. I suggest trying to use Tomcat 5.x to validate that things work properly. Tomcat is heavily used for development and testing by ICEsoft engineers so it's a good place to start.

If this works, then there is perhaps a network configuration issue preventing your from using the online demos. We'd be interested in knowing if a proxy server or firewall setup causes problems for ICEfaces applications.

If it works in Tomcat but not Sun's app server, that is also something we'd want to fix.

Deryk

Hello, Mike

Our internal testing for Firefox 1.5.0.2 shows that it works fine with the current release of ICEfaces. If you could be more specific about what is not working, we'd be happy to look into it. Are you having trouble with your own application or with one of demos? What application server are you running? What JSF implementation (Sun RI or MyFaces).

As for Opera, it's not currently an officially supported browser for our ICEfaces product. The beta version of 9 has just been released (which was after our own latest release). However, I just downloaded a copy of Opera 9 beta (Mac version) and pointed at our component showcase demo:

http://demo.icesoft.com/component-showcase/

I didn't run into any obvious problems. Again, if you could define more specifically what is not working (stack traces, logged errors), we'd be happy to investigate.

Hello, Linas.

All ICEfaces components (and other JSF components) rely on managed beans for their data. The structure and behaviour of those beans are the responsibility of the application developer. The method that the developer chooses to populate the data for those beans (EJB, Hibernate, web services, JMS, etc.) will have some influence over how efficiently it performs (CPU, memory, etc).

I agree that the code for the data paginator example in the component showcase would not likely scale well for large data sets. The sample applications were developed without requiring a database (to make them easier to distribute and run). However, it is outside the responsibility of the component to decide how and where to get its data. So to get to the bottom line, we don't have any plans to offer a component that does what you are asking. It'll be up to you to provide a mechanism for efficiently retrieving data from the DBMS. You can do this by modifying and extending the existing code from the example or by creating your own from scratch.

The other option would be to provide a generic backing bean of some kind that developers could use with the data paginator component. Is this what you meant? If so, we currently don't have any plans to provide it but I could recommend that it be added to our product roadmap for a future release.

Hopefully I've understood your question correctly. If I've got it wrong, feel free to put me back on the right path.

Deryk

Hey Amarish. Thanks for your question.

We don't officially support the portlet environment and haven't been running or testing ICEfaces with portlets. We did some preliminary work in the past to prepare the ICEfaces framework to work with portlets due to what we perceived as a high level of interest from potential customers at last year's JavaOne. However, our work since then has concentrated on other areas (e.g. Facelets) where customer demand has been more consistent.

If I had to guess (and was being brutally honest) I'd suspect that you'll run into serious problems pretty quickly if you try to use ICEfaces with portlets. Of course, don't let my opinion stop you from giving it a go and letting us know how it goes ;-).

The good news is that we make the input from these forums an important part of our planning. I'll make sure that portlet support makes it's way onto our roadmap in some way, shape, or form. Any additional information you can provide on your application requirements is always appreciated.

Deryk

ICEfaces Community Edition and Enterprise Edition both come with a set of custom components and one of these is the ice:dataPaginator. Used in conjunction with a dataTable, the dataPaginator can be used to render a set of page navigation facets and access attributes of the underlying DataModel specified in the associated dataTable. Using the dataPaginator, a dataTable containing a large DataModel can be viewed as multiple "pages" of table rows instead of as one large table.

You can find an overview of all the components that come with ICEfaces here:

http://www.icesoft.com/developer_guides/icefaces/component_overview/ICEfacesCompSuite.html

You can also see the components in action in our showcase demo:

http://demo.icesoft.com/component-showcase/

Deryk Sinotte