ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

That message typically relates the Ajax Push connection. Are you using Ajax Push in your application?

Is there anything in the server logs to indicate a problem?

If you use one of the browser client dev consoles (like FireBug), are there any other errors reported?

We'll need more information to be able to diagnose the problem.

No problem. Glad things got worked out.

What version of ICEfaces and what server are you running with?

Can you provide a copy of the rendered markup that the ice:command button generates to the browser? You might be overriding ICEfaces' onclick value with your own and thus preventing it from doing it's automatic Ajax correctly.

That certainly doesn't seem like the correct behaviour. Do you have a simple portlet .war file that shows the problem that you could post to the forum thread?

As for a diagnostic tool for turning off ICEfaces automatic Ajax form capture behaviour, try adding this attribute to the form:

Code:

 <h:form > 
     <f:attribute name="DISABLE_CAPTURE_SUBMIT" value="true" />
     ....

grubin wrote:

Specifically, I an ice:datatable in a portlet and I want to replace with a graphical representation of the data (very specific formatting needs--graphs won't do). The form includes about 12 ice:popups that I make visible and use as property editors, and I want specific clicks on the canvas to cause JavaScript to set a rendered=true..

Not 100% sure of the exact requirement here. Can you post a simple, stripped down portlet .war that shows the behaviour? My interpretation is that you want to click on elements in the HTML5 canvas and have those clicks adjust the render (or perhaps visible?) attribute of the various popups - is that right?

grubin wrote:

That brings up a subsidiary question: can I access the rendered property in my Bean from the JS function or do I have to have an invisible field on the page?.

You'd probably have to render something out when the value changes but you could pontentially use the JavaScriptRunner to set variables (or run existing functions that do the same thing) that your existing scripts could use:

http://res.icesoft.org/docs/v3_latest/core/api/

Re: Liferay 6.1 + icefaces 3.0 and ace components plugin for eclipse 3.7(indigo) + liferayide 1.5 plgin

(I'm shortening up the subject only because JForum is complaining that it's too long)

Looks like it might not be finding or loading the icefaces.jar for some reason. The FileEntryPhaseListener is part of icefaces-ace.jar but the EnvUtils class is in icefaces.jar.

Can you confirm that both jars are available to the running app?

Are you also able to build/deploy/run the samples/showcase/showcase-portlet example provided in the ICEfaces distribution in Liferay 6.1 to confirm that the basic enviroment is working?

If that all works then we'd need to take a closer look at how the plugins are working and what they are including during deployment.

Can you confirm the exact version of JSF and Glassfish that is being used with ICEfaces 2.0.0? Many bugs have been fixed between 2.0.0 and 2.0.2 so upgrading is recommended. The version of JSF used is also important.

To continue debugging, we'll probably need a few more details about the environment then because it's not entirely clear how you have this set up.

If I understand the setup correctly, you are using Liferay and have a portal page and one of the portlets on the page is an iframe portlet:

http://www.liferay.com/community/wiki/-/wiki/Main/Iframe+Portlet

The content of this iframe portlet is from an ICEfaces application so it's not a actually a portlet itself.

Assuming this is the correct understanding, then analyzing the stack traces, I have the following comments/questions.

The first exception likely isn't an actual session expiry. JSF doesn't actually detect session expiry on it's own. It does detect problems with ViewExpiredExceptions. That is, if a request contains information about ViewState and that ViewState can't be found during the RestoreView phase, then ICEfaces tries to examine the ViewExpiredException and see if they might have been caused by the session expiring. If so, it wraps it as a SessionExpiredException to try and make the cause of the problem clearer.

The second exception is likely because there is no valid UIViewRoot and happens because of the first exception.

So we need to debug why the ViewExpiredException is happening and the best way to start on that is to look at the javax.faces.ViewState value that is being sent with each request. You can use the console of your browser or Firebug or any other HTTP sniffing tool to do that. There should be a javax.faces.ViewState sent with each submission once a valid View and Session have been established during the initial page load.

Another thing to try is to run the web application in a page by itself (rather than through the iframe portlet). Do you see the same behaviour?

What version of ICEfaces are you working with?

Not entirely sure what you're asking for but do you need to prevent interaction with the page once a submission is made? Perhaps this is what you are looking for:

http://wiki.icefaces.org/display/ICE/blockUIOnSubmit

Additionally, the ACE Showcase example also comes in a portlet version:

Code:

icefaces.dir/samples/showcase/showcase-portlets

That you can build and deploy to Liferary 6.1 to see how the components work as portlets.

http://wiki.icefaces.org/display/ICE/Getting+Started
http://wiki.icefaces.org/display/ICE/Portlet+Development

Couple of things:

Can you be more specific about the exact version of ICEfaces you are using? It looks like it might be 2.0.0. The latest release on that track is 2.0.2 so perhaps upgrading might solve some problems.

You mention that you are using Liferay but the stack traces don't show any indication that the portal container (Liferay) or the PortletFaces Bridge are handling any of the requests. Are you running your application as a portlet or is it just a normal web application?

If you open a JIRA:

http://jira.icefaces.org/secure/Dashboard.jspa

and attach your fix, we'll look at including it in the next release.

http://www.icesoft.org/community/contribute.jsf

I've opened a JIRA for this issue:

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

My guess is that, because the CKEditor resources in question do not currently use JSF resource loading techniques, that the portlet bridge never gets a chance to do it's thing and encode them properly.

Getting Ajax to work properly with WSRP is a non-trivial challenge and is not currently supported in ICEfaces.

Ok, but we'll need more information to help troubleshoot the problem.

Is there anything in the logs on the server or perhaps in the browser console (e.g. Firebug in Firefox) that might provide a clue?

When you say "after a few clicks" can you be more specific about the steps that lead to the issue? Is the same number of interactions, the same order, a certain button that leads to the problem?

Can you provide the simplest .ear file that can be deployed to Glassfish that shows the issue in question?

Can you simply your application to remove the EJB requirement and then try running it on Liferay + Tomcat. Just try to remove Glassfish as a possible factor.