ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

BTW .. while I was writing the last message, my liferay session ended and here is what happened... both beans I mentioned, the one that mistakenly didn't get destroyed and the one that was created after the fact, both got destroyed.:

19:42:12,338 INFO [IncidentDetailBackingBean] Fatal rendering exception has occured, removing renderer. Message was:
com.icesoft.faces.webapp.xmlhttp.FatalRenderingException: fatal render failure for viewNumber 1
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:152
)
at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:142)

19:42:12,338 INFO [IncidentDetailBackingBean] Fatal rendering exception has occured, removing render
er. Message was:
com.icesoft.faces.webapp.xmlhttp.FatalRenderingException: fatal render failure for viewNumber 3
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:152
)
at com.icesoft.faces.async.render.RunnableRender.run(RunnableRender.java:142)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExec

19:42:12,353 INFO DetailBackingBean] Removing renderer for: com.myapp.backingbean.DetailBackingBean@487113
19:42:12,353 INFO [DetailBackingBean] Removing renderer for: com.myapp.backingbean.DetailBackingBean@d496be

This show that refreshing the portal page with the F5 key appears to be a culprit in this problem.

To take it further, I clicked the reload button at which point a new bean was created, while I had my console window frozen so I could see how many beans there were, the network connection lost box came up, when I hit reload.... I ended up with 4 of the same bean rendering.. which of course pigs the whole system down:

20:29:55,283 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.myapp.backin
gbean.DetailBackingBean@e48c4e
20:29:55,283 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.myapp.backin
gbean.DetailBackingBean@5eebe6
20:29:55,299 DEBUG [DetailBackingBean] Current detail has changed for DetailBacking
Bean com.myapp.backingbean.DetailBackingBean@e48c4e
20:29:55,299 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.myapp.backin
gbean.DetailBackingBean@39d7f0
20:29:55,299 DEBUG [IncidentDetailBackingBean] Current detail has changed for DetailBacking
Bean com.bae.gse.flare.backingbean.DetailBackingBean@5eebe6
20:29:55,299 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.bae.gse.flare.backin
gbean.DetailBackingBean@1f8a7df

Ok, one more go at this, I made a scaled down war file of my problem.

I also logged every time my request beans are destroyed and what their reference instance ID is in the JVM, so I can correlate when the beans get created, when their view gets invalidated and it gets destroyed. By doing this and scanning the log, I see a very peculiar exception happens at which point, I start ending up with duplicate request beans. It looks like this might actually be the fault of Liferay portal itself causing a failure of the removal of a bean from the interval renderer.... Here is what happens, and here is the setup of the bean's lifecycle I will follow:

In my bean, I define my variables like this:

Code:

 private final int renderInterval = 10000;
   private PersistentFacesState state;
   private RenderManager renderManager;
   private IntervalRenderer intervalRenderer;

I call this in my constructor:

Code:

 state = PersistentFacesState.getInstance();

[/code]

Here is how the renderManager gets set:

[code]public void setRenderManager(RenderManager renderManager) {
LOGGER.debug("Render manager is being set.");
this.renderManager = renderManager;
intervalRenderer = renderManager.getIntervalRenderer("periodicRenderer");
intervalRenderer.setInterval(renderInterval);
intervalRenderer.add(this);
intervalRenderer.requestRender();
}[/code]

Lastly for the setup, here is my renderingException method:

[code]public void renderingException(RenderingException renderingException) {
if (renderingException instanceof TransientRenderingException) {
LOGGER.info("Transient rendering exception has occured. Message was: " + renderingException.getMessage());
} else if (renderingException instanceof FatalRenderingException) {
LOGGER.info("Fatal rendering exception has occured, removing renderer. Message was: ", renderingException);
} else {
LOGGER.info("Unknown rendering exception has occured, removing renderer. Message was: ", renderingException);
}

if (intervalRenderer != null) {
LOGGER.info("Removing renderer for: " + this);
intervalRenderer.remove(this);
intervalRenderer = null;
}[/code]

Here is the log of how this particular bean gets created, destroyed and I think the reason I end up with duplicates:

It starts off with the creation of this bean id (I can't go far enough to get the line, but this is the only detailbean that has been created):
IncidentDetailBackingBean@19ffd2f

Next, since I'm not logged into the portal yet, I log in and I see that this bean is created:

19:11:37,039 DEBUG [DetailBackingBean] Render manager is being set for DetailBean
19:11:37,039 DEBUG [ApplicationImpl] Created bean detailBean successfully
19:11:37,039 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.myapp.backin
gbean.DetailBackingBean@11a7a64

That new bean renders one response cycle. Next, as I would expect, I see the first bean gets removed after I login (this isn't the last time I see this bean in the log though):

19:11:47,139 INFO [DetailBackingBean] Removing renderer for: com.myapp.backingbean.DetailBackingBean@19ffd2f
19:11:47,030 INFO [IncidentDetailBackingBean] Fatal rendering exception has occured, removing render
er. Message was:
com.icesoft.faces.webapp.xmlhttp.FatalRenderingException: fatal render failure for viewNumber 1

with the underlying cause:
Caused by: java.lang.IllegalStateException: getAttribute: Session already invalidated

Next, I don't see a creating message for this bean, but it all of a sudden appears in my log (I think I had refreshed the page):

19:11:50,630 DEBUG [DetailBackingBean] Current detail has changed for DetailBacking
Bean com.myapp.backingbean.DetailBackingBean@487113

I then next see the other bean die off:

19:12:09,723 INFO [DetailBackingBean] Fatal rendering exception has occured, removing render
er. Message was:
com.icesoft.faces.webapp.xmlhttp.FatalRenderingException: fatal render failure for viewNumber 1
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:152
)
Caused by: java.lang.IllegalStateException: getAttribute: Session already invalidated

19:12:09,832 INFO [DetailBackingBean] Removing renderer for: com.myapp.backingbean.DetailBackingBean@11a7a64

-----------------------------------------------------------------------
19:12:09,879 INFO [DetailBackingBean] Fatal rendering exception has occured, removing render
er. Message was:
com.icesoft.faces.webapp.xmlhttp.FatalRenderingException: fatal render failure for viewNumber 1
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:152
)

Caused by: java.lang.IllegalStateException: getAttribute: Session already invalidated
at org.apache.catalina.session.StandardSession.getAttribute(StandardSession.java:1032)

-------------------------------------------------------------------------------

After this, I see this message appear, but the interesting thing is that it's not followed by a remove method like the other ones were. The reason for this is probably because if you look above, the message only gets printed if the renderer inside of the bean wasn't null, but in this case it must have been. This looks like it attempted to destroy a bean that had already removed itself from it's rendering. When this exception occurred, this was the only bean rendering: the 487113 bean (I believe this one happened when I refreshed the page with the F5 button in firefox):

19:12:09,879 INFO [IncidentDetailBackingBean] Fatal rendering exception has occured, removing render
er. Message was:
com.icesoft.faces.webapp.xmlhttp.FatalRenderingException: fatal render failure for viewNumber 1
at com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:152
Caused by: java.lang.IllegalStateException: getAttribute: Session already invalidated

------------------------------------------------------------
After that destroy message that didn't seem to remove a bean from a renderer, I still see the bean that seemed to be attempted to be destroyed pop up again:

19:12:09,988 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.myapp.backin
gbean.DetailBackingBean@487113

The 487113 bean seems to render a few cycles and then a new bean appears along with a create message after:

19:12:16,129 DEBUG [DetailBackingBean] Current has changed for DetailBacking
Bean com.myapp.backingbean.DetailBackingBean@d496be
19:12:16,379 DEBUG [ApplicationImpl] Created bean detailBean successfully

19:12:16,379 DEBUG [DetailBackingBean] Render manager is being set for ResponseBean
19:12:16,379 DEBUG [ApplicationImpl] Created bean DetailBean successfully
-----------------------------------------------------------------------------------------

Now all of a sudden, both of those beans are now rendering:

19:12:16,955 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.myapp.DetailBackingBean@487113
19:12:16,955 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.myapp.DetailBackingBean@d496be

------------------------------------------------------------

So in conclusion, it appears as though when I refreshed the page, a fatal render exception occured, but no bean was removed. It looks like it meant to remove the 487113 bean when I refreshed, cause it was the only one that was supposed to be there... but instead it called the renderException method on a bean that was already removed!

Sigh, so I've been trying to reproduce my problem. If I scale down my app to the two problematic ones, remove all database and external dependencies, then it doesn't appear to actually do anything other than have the session expire.

But when I run my actual one, when I load the first page with only those two portlets, I see 2 of the same request beans rendering, I think two of each of the beans that are used for each of the portlets. I guess I'll just keep playing around until I can figure this out. I've narrowed it down to only using one IntervalRenderer for each bean, the only thing I had kept, was that one request bean references the other request bean to tell it that an even was fired (so that it can reinitialize it's variables, otherwise it's tricky to make every single property reinitialize itself every single time, also bad for performance and high probability of being buggy... I'm not sure what other way to exchange a change in state and easily reinitialize a bean.

No prob. I figured out that there was an inconsistency in how I added the paths for my custom images. Apparently I was prepending images in my code (I could have sworn I tried it both ways and it didn't work), so taking images/ off allowed my images to show up (this is wierd, because if that's the case, then setting the imageDir to ./images should never have worked, but it did).

As for the actual tree images, the only way I can get the tree images to work is to not include the imageDir attribute, if I include it at all, no matter where I point it, I end up with none of the tree control images. I'm not sure why I can't point it to "./xmlhttp/css/xp/css-images/", but that causes it to not load the images... maybe there is a small but in there somewhere?

No worries.. I figured rather than fiddle with it, I'm probably better off just asking instead. I probably won't give it a try as of yet though. One more question in this regard, so on a portlet page, if I wanted to use it.. the structure would be similar to:

<f:view>
<ice:portlet>
<ice:form>
</ice:form>
</ice:portlet>
</f:view>

I didn't realize the portlet spec actually specified styles, I guess I would know that if i could read it without falling asleep. :)

I was curious if anyone has used the ice:portlet tag in liferay. The 1.7 docs are a bit vague about using it and doesn't include an example. I'm assuming that it would be the next element after f:view? I almost got the impression maybe it replaces the ice:form element? The portlets seem to look fine without using it so I haven't tried it. Just curious if there is some benefit I don't know about by trying it. I think the docs mentioned about automatically picking up the theme of the container if you use that tag as well, but I'm not sure what that means.. such as do I remove all style information from the components? Do I remove the outputStyle tag?

Thanks!

Doing that makes all the text and components a lot bigger than how they are normally in the liferay theme... this doesn't appear to help me get my icons to appear in the tree though. I guess I'll do a copy of all the resources straight into my webapp and set the images directory to point to that.. it's strange it works that way and not the other way..

One more interesting note, I tried logging out of the liferay portal and logging back in, I get about 40 views that are listed as now invalid. When I log back in, the request beans start behaving for my single user (I don't have duplicate IntervalRenderers trying to render the same view to the same portlet). I don't seem to have request beans spawning out of no where anymore.

This seems to indicate a liferay portal problem?

In liferay 4.3.1 if I do this:

<ice:outputStyle href="xmlhttp/css/xp/xp-portlet.css" />
...
<ice:tree id="detailsTree" value="#{detailBean.detailTreeModel}"
var="item" hideRootNode="false" hideNavigation="false"
imageDir="./xmlhttp/css/xp/css-images/">
...

then the Tree component will render with no style, it will just print out the names of the nodes.

If I do this:

<ice:outputStyle href="xmlhttp/css/xp/xp-portlet.css" />
...
<ice:tree id="detailsTree" value="#{detailBean.detailTreeModel}"
var="item" hideRootNode="false" hideNavigation="false">

The all my styles render properly for my tree EXCEPT for the image for my icons. Those will not render, even though I'm using the graphicImage like this (I have another graphicImage tag that is referencing images the same way, in the directory, but not in a tree and it works):

<ice:panelGroup style="display: inline">
<ice:graphicImage
value="/images/#{item.userObject.icon}"/>
<ice:commandLink
actionListener="#{item.userObject.activate}">
<ice:outputText value="text"/>
</ice:commandLink>
</ice:panelGroup>

The text will display, but no image. I do get the tree XP styles applied.

If I do this:

<ice:outputStyle href="xmlhttp/css/xp/xp-portlet.css" />
...
<ice:tree id="detailsTree" value="#{detailBean.detailTreeModel}"
var="item" hideRootNode="false" hideNavigation="false"
imageDir="./mages/">
...

and reference the webapp image directory, my icons will then load in the tree, but the styles will no longer load. Do I have to copy all of the images out of the icefaces jar into my webapp to make this work?

One more question, I'm wondering what happens to an interval renderer after a request bean goes out of scope? Do they get disposed of correctly in icefaces 1.6.1? Is there a reference to the beans somehow in icefaces keeping them from being garbage collected?

Here is a snippet from my log where things are going haywire. Currently I have 4 different portlets on the page. One of the request scoped beans in particular is very obviously attempting to render multiple times at the exact same time. The network connection keeps timing out because requests take too long to complete due to the fact I have more request beans than I should have. Here are some snippets in case you can suggest something. The bummer is I was able to deal with some of the slowness before but now our app is unuseable. Last night I noticed after 2 or 3 minutes of clicking around in the app, it started talking about view number 76 ... which if I haven't logged out and only have 4 portlets... I should have 76 views.....

The following shows I think that there are 5 request beans attempting to update the view of the single portlet? Is there something I can look at to see if I'm misconfigured? I don't seem to see anything:

-------------------------------------------------------------
13:42:27,494 DEBUG [ValueBindingImpl] getValue(ref=responseBean.responseList)
13:42:27,494 DEBUG [OutputStyleRenderer] OutputStyleRenderer: Request is not HttpServletRequest. Its
[com.icesoft.faces.env.PortletEnvironmentRenderRequest]
13:42:27,510 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.notification.backin
gbean.ResponseBackingBean@5ec877
13:42:27,525 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.notification.backin
gbean.ResponseBackingBean@1f96f01
13:42:27,541 DEBUG [ValueBindingImpl] getValue(ref=responseBean.responseList)
13:42:27,541 DEBUG [ValueBindingImpl] getValue(ref=responseBean.responseList)
13:42:27,557 DEBUG [ValueBindingImpl] getValue(ref=responseBean.responseList)
13:42:27,557 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.notification.backin
gbean.ResponseBackingBean@1f91958
13:42:27,557 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.notification.backin
gbean.ResponseBackingBean@1aee7be
13:42:27,604 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.notification.backin
gbean.ResponseBackingBean@15a87c0
---------------------------------------------------------

Next, here is a snippet of my log that almost seems to indicate liferay might be doing something it shouldn't be doing:

----------------------------------------------------------------

13:45:54,871 DEBUG [VariableResolverImpl] resolveVariable: Resolved variable:com.notification.backingbean.ContactNode@fb289b19
13:45:54,871 DEBUG [ValueBindingImpl] getValue Result:null
13:45:54,871 DEBUG [RenderResponsePhase] Exiting RenderResponsePhase
13:45:57,465 DEBUG [LifecycleImpl] execute(com.icesoft.faces.context.BridgeFacesContext@68c43d)
13:45:57,465 DEBUG [LifecycleImpl] execute(com.icesoft.faces.context.BridgeFacesContext@a52b44)
13:45:57,465 DEBUG [LifecycleImpl] execute(com.icesoft.faces.context.BridgeFacesContext@e1a7f)
13:45:57,465 DEBUG [LifecycleImpl] execute(com.icesoft.faces.context.BridgeFacesContext@17d37fa)
13:45:57,465 DEBUG [LifecycleImpl] execute(com.icesoft.faces.context.BridgeFacesContext@ef112)
13:45:57,465 DEBUG [LifecycleImpl] render(com.icesoft.faces.context.BridgeFacesContext@68c43d)
13:45:57,465 DEBUG [LifecycleImpl] render(com.icesoft.faces.context.BridgeFacesContext@a52b44)
13:45:57,465 DEBUG [LifecycleImpl] render(com.icesoft.faces.context.BridgeFacesContext@e1a7f)
13:45:57,481 DEBUG [LifecycleImpl] render(com.icesoft.faces.context.BridgeFacesContext@17d37fa)
13:45:57,481 DEBUG [LifecycleImpl] render(com.icesoft.faces.context.BridgeFacesContext@ef112)
13:45:57,481 DEBUG [RenderResponsePhase] Entering RenderResponsePhase
13:45:57,481 DEBUG [RenderResponsePhase] Entering RenderResponsePhase
13:45:57,481 DEBUG [RenderResponsePhase] Entering RenderResponsePhase
13:45:57,481 DEBUG [RenderResponsePhase] Entering RenderResponsePhase
13:45:57,481 DEBUG [RenderResponsePhase] Entering RenderResponsePhase
13:45:57,481 DEBUG [RenderResponsePhase] About to render view /message_response.iface
13:45:57,481 DEBUG [RenderResponsePhase] About to render view /message_response.iface
13:45:57,481 DEBUG [RenderResponsePhase] About to render view /message_response.iface
13:45:57,481 DEBUG [OutputStyleRenderer] OutputStyleRenderer: Request is not HttpServletRequest. Its
[com.icesoft.faces.env.PortletEnvironmentRenderRequest]
13:45:57,481 DEBUG [RenderResponsePhase] About to render view /message_response.iface
13:45:57,481 DEBUG [OutputStyleRenderer] OutputStyleRenderer: Request is not HttpServletRequest. Its
[com.icesoft.faces.env.PortletEnvironmentRenderRequest]
13:45:57,481 DEBUG [RenderResponsePhase] About to render view /message_response.iface
13:45:57,481 DEBUG [OutputStyleRenderer] OutputStyleRenderer: Request is not HttpServletRequest. Its
[com.icesoft.faces.env.PortletEnvironmentRenderRequest]
-----------------------------------------------------------------

Is there a reason why liferay seems to have so many instances of BridgeFacesContext?

Glad you made it through the post. :) I'm hoping that I can get all this clarified so I can learn to happily use Icefaces, since I really think this kind of technology will make a huge difference in our app.

The problem with making the bean an application scoped bean is because I still have other portlets using it that I haven't converted over to icefaces. Since they will all be in the same war, I should be able to use the application scope. I don't know how application scope is handled in a portlet across multiple wars, so I stuck with a session scoped bean.

I actually am doing something similar to this for my intervalrenderers:

public String getSomething(){
state = PersistentFacesState.getInstance();
...
}

except that I'm taking the property of my bean that needs the information from a webservice and then calling the webservice at that point. The problem is that I need the renderers to be more lightweight to allow a higher user capacity. The other problem is that a lot of the data coming from the webservice is global to all users in the portlet, so until I figure out how all users can be pushed that data at the same time, while only making one call to the webservice, I'm wasting a ton of processing (my previous ajax tool was way worse, so I really can't be all that hard on icefaces).

I thought about getting the PersistentFacesState each time the session bean rerendered, but I wasn't sure if there were any technical reasons that I couldn't do it, it also took me forever to find the post that explained that this will happen and I'm not sure if this would have to be put in every property? Or just one property? Now that you mention it, that error makes sense in the context of a stale PersistentFacesState.

I may have mispoken about icefaces being fragile because I think I'm lumping several things together, some of which are known as technical limitations already, that were causing my application to stop rendering updates. The reason I would say fragile is because if an application stops rendering updates without any warning, that leads a user to a false sense of what's going on. In a mission critical app, this could be really bad. If I knew that the renderer would keep rendering the views as they change, baring any bugs in the code, then I wouldn't call it fragile. Because of the PersistentFacesState technicality, I really don't have as much reason to say it's fragile, other than the fact it would be nice to have a visible warning indicating such an issue.

I hope so, I think icefaces has a lot of promise and if I can show my uppers that this technology is reliable and scaleable, I can then talk them into using it for other projects.

Currently our Web Service calls are not asynchronous. I've had quite a few hurdles to get over in general with the soap stack we are using, so I haven't pushed it that far yet. If I am able to make the asynchronous calls, then that might allow me to alleviate some of the load. The problem still comes about that I would have to have an IntervalRenderer "fake" render the bean just so a web service request will be kicked off. I would then probably register the bean for the call back, at which point I would then tell the bean to rerender. It would be nice if icefaces allowed a mechanism to simply have it call a function that MIGHT produce a change in state for the application and if it does, it could update the appropriate properties and then invoke a render. I think though we would be fine if I could simple has one webservice request invoked and then all clients updated with that data. As it stands right now, I think the only thing you can do, is tell all the clients to rerender, which will then make each bean for each client make a call to the webservice. I thought about putting a lastOperationTime variable so that whomever makes the call first will get to make it and then rest will see that the call was made too recently and skip it. The problem is that they will miss retrieving the data for their client. I guess I'm not sure if the icefaces team already has a better solution in mind for this scenario, or if it's still being fleshed out.

Sounds good, I'll be perfectly ecstatic if I'm wrong on at least most of these issues since it means that what I'm hoping icefaces can do for our app, is still possible.

I'm a bit under the gun currently for the next few days, so I'll try to get a couple test cases together for you that illustrate some of these issues.

I've spent the last few days really pounding on icefaces and seeing what it can do with our portlet application in Liferay 4.3.1. I've been a little disappointed since I'm concerned a little about reliability/scaleability/performance. Here are the things that I've run across that are either a problem, frustrating or are merely a hiderance in my experience (these are all asychronous communications, and I've moved all my portlets to the same war, which sucks, but oh well and also I've tried 1.6.0, 1.7DR1 and 1.6.1):

1. Initially I was trying to create a preferences session scoped bean which could be retrieved by other beans to get global preferences from a database (as a way to centralize retrieval of database properties (and attempt to make it more efficient, by caching some values). Each session bean that tried to obtain a reference to the preferences session bean (since it's session scope, long as I'm the same user, I should get the same one), ALWAYS retrieved a new instance of it (whether I looked up the JSF binding myself, or wired them in faces-config.xml). I confirmed this with a debugger. Also, a Session beans PersistentFacesState becoming stale after something as simple as a row selection (on a datatable), is a pain as well, since I had to give up on session scoped beans at that point (all my beans stop rendering after a click, or well they render but the updates won't show anymore).

2. In reference to #1, a similar problem exists with Session beans. Request scoped beans appear to replicate faster than rabbits. With only a single user (myself) hitting our application, the views active sometimes managed to get up to 16 with asynchronous communications (this is with just two portlets on the screen). In the log, I could see new references for the same session scoped bean class keep appearing. I discovered that icefaces seems to ALWAYS use a new bean, never one that is currently in existence. This really became apparent as I was trying to use an action-listener model to have one request scoped bean trigger an update on another request scoped bean (this is because I had to give up on the session beans). Every time I clicked a button to trigger the action on the other request bean, icefaces would create more and more request scoped beans, all of which added themselves as listeners.. this caused quite a bit of havoc.

3. I noticed today this bug report:

http://jira.icefaces.org//browse/ICE-1158

I'm assuming this is still a problem today. Last night after a lot of panicking about how I was going to get around the out of control request bean spawns, I noticed that the action monitor demo uses server saved state. I was using client saved state because that's what the liferay icefaces portlet uses and that's what I began modeling my icefaces portlets after. Server saved state appears to work better from the little I've played with it, but not sure yet. Either way, the inconsistency makes things a little difficult.

4. Icefaces is VERY fragile, including a wrong jar from another dependency (such as using a CXF webservice client from a portal, drags along the jetty jars which renders your application useless). Unexpected errors are tough, since it seems very hard to tell how to recover and still have an interval renderer stay current. I run into problems every once in a while where my asychronous thread stays running, but the screen just won't update anymore.

5. The following error has been driving me nuts:

WRONG_DOCUMENT_ERR: A node is used in a different document than the one
that created it

Every once in a while, my asynchronous interval renderer will just start throwing this error on the screen. Sometimes due to a previous error in my code, sometimes for no apparent reason. One thing I had to do was move an interval renderer from 5 seconds to 10 and then that problem went away. I've slowly been moving my interval renderers timer to bigger and bigger interval amounts (currently around 30 seconds, hardly realtime anymore but oh well), because it seems like icefaces can't handle it, due to unnecessary beans spawning and other weird errors such as:

Unable to leverage base class java.lang.IllegalStateException
at
com.sun.faces.taglib.jsf_core.ViewTag.getComponentType(ViewTag.java:259)
at
javax.faces.webapp.UIComponentELTag.createComponent(UIComponentELTag.java:219)
...

I still haven't figured out what causes that error but it will just popup sometimes when I start the portal for testing. No idea what causes it.

6. I'm having trouble understanding how to handle larger tasks for asynchronous rendering. I've guessing some of my problems might just be the workload that my portlets are doing. We make a lot of web service calls, and I've been trying to use the asychronous renderers to prevent the browser from going crazy updating quite a lot of dynamic content. The biggest problem though, is that it's mentioned in the docs that render calls are expensive and that you should be careful what you are doing in those calls. The problem is that there is no other choice BUT to do all the work you have to do, in the renderers, like an interval renderer, if the update isn't triggered by a user. If you have a webservice, like a ws-notification service that you are using to retrieve updates and pump them out to your users, all the work HAS to be done in the interval renderer. The only other option is to create a whole new set of threads to tell your renderer to kick off. This would be great, but I can't find anywhere how to safely do it (in J2EE stuff, you really aren't supposed to be creating unmanaged threads from what I'm told).

I think this is enough for now about what I've encountered (there are a few more things, but I'll be lucky if anyone finishes this post). I've guess that architecturally I'm not understanding how to leverage icefaces properly, which is fine. I wish there was a document that would tell you how to handle monitoring web services for updates in order to propogate the changes down to a user. I really like icefaces in general, but I'm a bit worried at this point about reliability. If anyone has any suggestions, it would be greatly appreciated.