ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Support for WebSphere currently requires

- RAD version 6.0.1 or later
- WebSphere 6.0.2 or later

If you are using WebSphere 5.1.x as the subject suggests then you'll likely run into difficulties. If support for older versions of RAD and/or WebSphere are mandatory for your project, you could contact support/sales directly about your requirements.

Deryk

Thanks for providing the code. We've replicated the behaviour and found a synchronization bug as suspected. We'll work on getting it fixed for the next release.

Deryk

Oops. Two mistakes.

First, the !clock.contains() should have been clock.contains().

Second your right about the contains() method. For some reason it's private. I'll mark it as a bug to be corrected in the next release. Sorry to mislead you.

The NullPointerExceptions do indicate a problem unrelated to the GroupRenderers.

What app server are you using?
What JSF implementation are you using?
Are you using other JSF components besides ICEfaces?

The error indicates that it can't properly get the appropriate render kit.

Does the application work if you disable the server-side renderers?

It would help to have a bit more information about your application because the behaviour your are describing should not necessarily be happening in a simple ICEfaces application. In a typical scenario, if your backing beans are in session scope, each client should get their own instance and have their own "state" so there should be no synchronization issues.

Maybe you could fill in some details:

How is the button component bound to the backing bean? Is it an h:commandButton bound to a method using the actionListener attribute?

What is the scope of the backing bean? Request, Session, or Application?

What does the bound method attempt to do? Is it a long lived operation? Does it use any structures or collections that are shared across multiple user sessions?

If it's possible and easier, maybe you could zip up and attach the relevant code.

Deryk

As a quick fix to cut down on the warning messages, you could modify your logic to check if the Renderable is actually contained with the Renderer before attempting to remove it:

[pre]
public void renderingException(RenderingException renderingException) {
if( clock != null && !clock.contains(this) ) {
clock.remove(this);
clock = null;
}
}
[/pre]

Also, if your bean has gone out of scope, you should remove it from all Renderers (Interval and OnDemand). The renderingException callback can be called from any render you added the Renderable to.

So the output is telling me that you probably have an IntervalRenderer (a subclass of GroupAsyncRenderer) called "clock".

Judging by the timestamp and the RTBERBean hashcode, it looks as if your application is repeatedly trying to remove the bean from the IntervalRenderer - perhaps in a tight loop. If you attempt to remove a Renderable from the IntervalRenderer and it no longer is contained in the collection, you'll see this message. It's a relatively benign warning.

Typically you would only remove the bean once (e.g when it goes out of scope). Is it possible for you to post or attach a code snippet where the remove() method is called?

Deryk

That's really more of a WebSphere question than an ICEfaces issue so I recommend wading through IBM's documentation:

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/welc_howdoi_tapp.html

There are several different methods that IBM recommends.

1) You can use the IBM's WAS IDE to build your applications and then deploy and update them from the IDE to the server. This seems to be the slickest method as long as you don't mind using their IDE. Some other IDEs may provide WebSphere integration (I see IntelliJ has something for WebSphere in their version 6 early access release).

2) You can run scripts (written in either JACL or Jython) that can access objects provided by WAS to do deploys and updates. WAS provides a wsadmin.sh script for running your custom scripts

3) You can try to use Ant but from what I read, it's not as straightforward as it could be as you need lots of libraries from the WAS installation along with the custom Ant tasks.

Deryk

Couldn't agree with you more. A number of us at ICEsoft use IntelliJ so we'd all be interested in better integration. ;-)

Not to be nitpicky but ICEfaces is not technically a JSF implementation like Sun's RI or Apache MyFaces. It's a Render Kit and set of integrated features that works with an existing JSF implementation. So you'd have to pick Sun RI or MyFaces anyway. However, it would be nice to have a checkbox you could tick that said "Include ICEfaces support".

We are doing our own tool integration with Eclipse, JDeveloper, etc and IntelliJ should make it on the road map in the future. The best way to get these types of features is to keep asking for them. Hopefully you post to the JetBrains forums as well so they know what features you want to see.

Thanks for all the good feedback,

Deryk

Just to follow up my last post, concurrent DOM views will work properly providing that the User bean is set to request scope. If you need to have logic in session scope than you may need to divide your work between multiple beans with different scopes.

Deryk

I'm assuming that the behaviour you desire is that when you update the data in one window and click the button, you would like all the other clients that are pointed at that application to be updated as well. There are different aspects to this problem so I'll try to address them one at a time.

First of all, I'm going to pretent that we are pointing a single window from two different browsers (e.g. IE and Firefox) at the same application application. This is different than pointing two different windows from the *same* browser at the same application.

1) In the presented application, User is a session scoped bean which means that each separate browser window gets its own session. Since the data you are retrieving is right in the session bean, this is stored separately for each User. So when you change the data in one and then request a render call, the other clients are updated, it's just that their data has not changed. The PersistentFacesState associated with each User is exposed to the OnDemandRenderer by implementing the Renderable interface - which has been done correctly. However, this state can only be set reliably in the constructor of a session scoped bean. If you change User to be application scope, the PersistentFacesState reference will be set for the first User (let's say User1) that accessed the application. What you will see then is that submits from subsequent Users (User2,User3,User4,etc) will properly cause a re-render of User 1 (because that is the PersistentFacesState that has been set) but clicking the submit button of User1 will not update the view of other users because the application bean only has the single PersistentFacesState for User1. To fix this, keep your User bean as session scope then add a third bean (let's call it Data) that is application scoped and that all the session beans can reference. Store and retrieve data from this bean (think of it as a world's simplest database).

2) So now it should work for a single window in different browsers. If you want to be able to point at the application from two windows in the same browser, then you need to know about concurrent DOM views. The Developer's Guide has more information so I encourage you to look there. In short, if you point two windows of the same browser at the same application, you can get unpredictable behaviour since the browser will use the same session, and therefore same server-side DOM, to handle both windows. As Philip described, we provide a context parameter for turning concurrentDOMViews on (it is off by default). By setting this parameter to true, you should be able to have two IE windows open and pointed at the same web application while still maintaining two distinct "views" of the application. However, I think we may have a bug with this feature as my testing shows some unreliable updating. For now I'd recommend not relying on this for your development and testing and use two separate browsers.

Deryk

> Hi, i starting with icefaces it seems to me very ,
> very nice, but i have several questions.
>
> I'm working in an application based on the TimeZone
> example and i have the following questions:
>
> In this example there is a manage bean called
> timeZoneBean and is rendered through an
> IntervalRenderer, everything was well until i wanted
> to add an h:inputText with a h:commandButton to the
> timezone.jspx page with its corresponding managed
> bean property.
>
> Now i point two browsers to the application and the
> problem is that when i introduce some text in the
> h:inputText and click the buttom of one of the
> browsers the other don't refresh the change. Why?
>
> I think if my managed bean property change in the
> next render of the IntervalRenderer all the browsers
> have to update its UI components. I'm wrong?
>

This depends on the scope of the managed bean and how the state is retrieved. If the bean is request or session scoped, then the change will only affect that session (ie one particular client). If you get the state/data from a shared resource (like an application-scoped bean, a database, a webservice, etc), then the state can be updated for all users.

Other than where the state is retrieved from, the other important point is the PersistentFacesState. Each state that is added to a GroupRenderer is updated when requestRender is called.

> The IntervalRenderer only refresh the views of the
> session that caused the change?
>
> Can i use in the same managed bean more than one
> GroupAsyncRenderer type, for instance an
> IntervalRenderer and an OnDemandRenderer?

Any of the GroupRenderers can render multiple clients and you can use multiple renderers for a managed bean.

>
> When a GroupAsyncRenderer is executed in a specific
> bean it refresh all the views that make reference to
> that bean?

The GroupRenderer is used in a managed bean but it is really associated with the PersistentFacesState that is added to the group. Whatever state is available is rendered. All beans that are referenced and visible in the current view are queried for their state.

Deryk

All the components on a single page constitute a unique view. Whenever that page/view is required to re-render, all the beans backing those components will be queried for their data. So if I understand your application correctly, yes, all the managed bean values that are referenced on that page will have their accessor methods called.

This is the current design, not a bug, so we have no plans to fix it. If your application is running into resource problems due to having everything on a single page, I can only think of a couple of potential changes that might help.

1) Split up the functionality into multiple pages. This may be undesirable from a UI perspective (replacing the tab panel with separate pages) but if you are resource constrained, it's one possible option.

2) If your beans are doing resource intensive activities (for instance they all make calls out to the database) it might be prudent to insert some kind of simple data-caching layer that does all the fetching and have the beans interact with this layer.

Just so that I'm clear, are the accessors for *all* the referenced beans being called or just the ones that are set as rendered and/or visible? That is, are the accessors for beans that are on non-rendered and/or non-visible panels being called as well?

It is by design. All of the different GroupRenderers (like IntervalRenderer) kick off a JSF render cycle when the render call is made. During the render cycle, an attempt is made to reconstruct the current state of the DOM so that it can determine the differences to send back to the client.

However, to get this current state, it must pull all the relevant values from the backing beans for the current view - not just the bean where the RenderManager is registered. So if you have 30 managed beans that are all referenced on the current page, they will all be queried for their current state.

As for performance concerns, that will depend on the size and complexity of the page in addition to the operations required for the beans to update their state (i.e. database queries, external services, etc.).

It would be interesting to provide some kind of programmatic control over what portion of the view should be updated, but it currently is not that fine grained in the current ICEfaces release.

Deryk

Sorry the reply wasn't as prompt as you hoped but our office is based in North America and we don't have 24/7 support so we can only generally reply during office hours.

As to your questions:

1) ICEfaces is not really a framework by itself. It is an extension to JSF, which can more properly be considered a framework. To learn more about JSF, you can start here:

http://java.sun.com/javaee/javaserverfaces/

There are many additional resources for finding out about JSF.

2) JSF is a component-based framework for building rich web applications. It is meant to be used with either JSPs or Facelets (https://facelets.dev.java.net/) as the view technology. You can also use standard "include" mechanisms to integrate ICEfaces technology with existing JSPs.

3) One of the original goals of JSF was a replacement for Struts. It hasn't been completely successful in that regard for a number of reasons but there are efforts out there to integrate JSF with Struts (Google for jsf and struts to find them). Since ICEfaces is built on top of JSF, we don't provide a specific way to integrate with Struts.

Do you have an existing application you are looking at upgrading or are you considering building a new application based on JSF, Struts, ICEfaces, or some other technology?

I downloaded version 5.2 of EAServer for Windows and tried running component-showcase from the Community Edition 1.0.

The BlockingServlet handles all incoming traffic by overriding the HttpServlet.service() method. I'm not very experienced with EAServer but it seems that the issue is related to doing a POST. All GET oriented requests appear to work correctly.

User interaction is handled by POSTs and it appears that the request.getParamterMap() call is not returning any parameters when the request method is a POST.

Here is a couple of examples of some debugging output that I captured. First from a successful GET:
<pre>
Jun 07 13:09:26 2006: ** DUMPING REQUEST INFO **
method : GET
request URI : /component-showcase/block/ping
context path: /component-showcase
query string: focus=undefined&icefacesID=-847318111%2C&viewNumber=1%2C&rand=0.
1779242400082468
params :
key: focus
val: [Ljava.lang.String;
key: icefacesID
val: [Ljava.lang.String;
key: rand
val: [Ljava.lang.String;
key: viewNumber
val: [Ljava.lang.String;
content :
</pre>
Then from an unsuccessful POST:
<pre>
Jun 07 12:40:15 2006: ** DUMPING REQUEST INFO **
method : POST
request URI : /component-showcase/block/send-updates
context path: /component-showcase
query string: null
params :
content :

focus=undefined&=&navigationMenuForm%3A_id12%3An-2%3A_idcl=& [etc....]
</pre>
The POST actually contains all the form data we need for processing but those values are not being added to the parameter map for some reason. The NullPointerException in the BlockingServlet comes from not being able to retrieve one or more of these values.

So I guess my question is - Is there a known strategy or problem with EAServer that prevents POSTed form parameters from being added to the request's parameter map?

Deryk