ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

ekatus.atimoss wrote:

Strong indication that this is browser related. Was not able to reproduce the bug using Eclipse Internal Browser (3.5 on Windows XP) or IE 6. Bug shows in FF 3.x (3.5.5)

kind regards
Michael

I'm afraid this bug

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

is back or still persists in beta1. Browser is FF 3.6.8, Mojarra 2.0.3, GlassFish 3.0.1 (EN). The <ice:commandButton> action method get's called even though the button is not pressed.

kind regards
Michael

Update:

I've removed the GF 3.0.1 ML (Multi-Language) installation and installed a fresh GF3 EN (English).
I then copied the jsf-api.jar and jsf-impl.jar from the Mojarra 2.0.3 installation to the glassfish\modules directory.
after starting GF via asadmin, I launched the web console and installed dyninc.war.

The example under "ice" works as it should be, that is, click events are processed in time and the "double click" bug has dissappeared.

I will now try this with the 1.8. compat feature - looks like a great step forward in running the 1.8 / JSF 1.2 App under GF3 with JSF2.0 and ICEfaces 2.0

I will post another update when I get the results.

regards
Michael

Unvirtual wrote:

I had the same Problem by development too, and had found the icefaces.jar in my ear module and in war file. That was the only problem.

The dyninc.war test comes with icefaces Jars in WEB-INF/lib _and_ the bug, so we still have a problem here (no ear module). I'm currently investigating why Mojarra 2.0.3 jars in glassfish/modules still give me a 2.0.2 banner in the server.log.

kind regards
Michael

It reads

Mojarra 2.0.2 (FCS b10)

Ok, I will do some further research - I simply deployed your dyninc.war in a standard GlassFish V3.0.1 downloaded from Oracle. So no Eclipse here.

(it did not work from being imported into an Eclipse Project and deployed to the same server using the Eclipse GlassFish plugin).

Maybe I can record the interaction and post it as a movie.

Kind regards
Michael

Hello!
Here's my update. For some odd reason, Deryk's example works under plain Glassfish 3.0.1 - that's for the good news. The bad news is - dynamic include is still broken, for icefaces only. stock jsf works with the Window scope. The path for icefaces shows the "second click" behaviour as soon as one page navigation has been performed, e.g.

choose "ice"
enter data & navigate - OK
navigate again - NO reaction
navigate again - navigation performed

choose "stock"
enter data & navigate - OK
navigate again - OK
navigate again - OK

kind regards
Michael

Dear Deryk, der Judy,

imported the war into ECLIPSE and tried it on GlassFish 3.0.1. (eclipse plugin) to no avail - the nagivation fails with the paths included. I try a clean deploy of the war directly via the GlassFish admin console next.

Please see the screenshot attached.

Kind regards
Michael

Yes, same problem. Browsing the web, recommended workaround is to add
Code:

 <context-param>
         <param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
         <param-value>false</param-value>
  </context-param>

to the web.xml - The difference is, the workaround works for plain JSF2.0 but breaks in Icefaces 2.0 beta1. The question now is - will that be fixed? Can we use PARTIAL_STATE_SAVING=false in the future?

Kind regards
Michael

As promised, the ultra-slim web-app example that will visualize the error. No EJB, no Database, just one Bean and 4 Web Artifacts.

Supposed operation:
index.jsp forwards to /sample.xhtml, which ui:includes the content as indicated "path" property of DemoBean (/input.xhtml)
input.xhtml has an ice:inputText component, an ice:commandButton and an ice:messages component. The content of the ice:inputText is stored in DemoBean.name. Upon clicking the ice:commandButton in /input.xhtml, the DemoBean.doClick() method is called. This method reads the value of the name propertie, concatenates it with an constant string and puts the value as a faces message. Finally, the path property is set to output.xhtml. This facelet contains only ice:outputText, ice:messages and an ice:commandButton.
It is expected that after leaving this method, the view is rebuild and the new path (output.xhtml) is included, showing what was entered previously.
Upon clicking the ice:commandButton in output.xhtml, the method DemoBean.close() is called which sets the path to input.xhtml. It is expected that the view is rebuild with the content of input.xhtml included.

A) PARTIAL_STATE_SAVING=true
Upon clicking the ice:commandButton in input.xhtml, the method DemoBean.doClick() is called as expected, but the view is not re-rendered and thus the new value for path not included via ui:include.
Upon clicking the button again, the method is executed and the view is regenerated, showing output.xhtml.
Clicking the button in output.xhtml, the method DemoBean.close() is called as expected, the path is set to input.xhtml, but the view is not re-rendered and thus still showing the output.xhtml. Clicking the button again executes the method DemoBean.close() again, but this times re-renders the view and shows the content of input.xhtml.

Conclusion: not really for the faint-heart end-user

B) PARTIAL_STATE_SAVING=false
Upon clicking in the inputText and leaving with tab OR clicking the commandButton, the application immediately breaks with the "viewstate already found" exception at com.sun.faces.util.Util.checkIdUniqueness(Util.java:724)

Conclusion: broken.

Executed under Windows XP on GlassFish 3.0.1 using Mojarra 2.0.3

Kind regards
Michael

Oh, I'm not asking for free support - just wanted to make your upcoming product release better - my interest is, of course, to find out how ICEfaces will provide a migration path from 1.8 to 2.0 - the problem in question is easily to be recreated and did not show up in alpha1 - it looks as if it is bound to the parameter PARTIAL_STATE_SAVING=false. With this being set to false, the web app breaks completely, being set to true, it's just unusable. So my workaround from alpha1 did not last through beta1.
Anyway, I understand that the ICEfaces team is very busy so I try to come up with a much simpler, non-EJB web-only example showing this bug.

Kind regards
Michael

This is everything packed as Eclipse projects. Hope it's not too big.

kind regards
Michael

Hello!

I have a live project under 1.8 and Mojarra 1.2 and Tomcat6 and am preparing having to switch to GF3 / Mojarra 2 and IceFaces 2.0 one day.

Probably you remember my previous posts from back then, when trying to preserve the 1.8 behaviour in my beans - the title of the topic was From 1.8.2 to 2.x - fundamental change in page nav required? and the solution was to include PARTIAL_STATE_SAVING=false in the web.xml - which now seems to cause other trouble. The remedy for this - PARTIAL_STATE_SAVING=true causes the unwanted behaviour that the view is not refreshed upon the first click.

--- edit ---
I want to be able to use a pattern like

public String myCommandMethod() {
acmeService.doSomething();
return null;
}

in my page backing beans and something like

public String openDetailPage() {
this.pathToPage = PAGE_DETAIL;
return null;
}
with an facelet like
Code:

 ..
 <ice:commandButton value="Open Detail" action="#{navBean.openDetailPage}" partialSubmit="true" />
 ...
 <ui: include src="#{navBean.pathToPage}" />
 ...

I have prepared a little demo project which I could upload - I'd just clean out all the common jars from WEB-INF\lib to economize on upload size.

kind regards
Michael

Dear forum,

same trouble here - either having PARTIAL_STATE_SAVING=false and getting the iewstate has already found in the view error with beta1 or PARTIAL_STATE_SAVING=true and having to click twice on a control - which is of course not possible in a real application.

IceFaces 2.0 beta 1
GlassFish V3.0.1
Mojarra 2.0.3

To me, moving to IceFaces 2.0/GF3 is as far away as months ago...

kind regards
Michael

Dear Forum,

in my 1.8.2 app, I use a pattern quite often where after leaving a field or selecting a drop down, a partitial submit is performed and a ValueChangeListener for that control is called. New values are calculated in the ValueChangeListener method and to prevent these values from being overwritten, I have the listener called in the INVOKE_APPLICATION phase.
Under JSF2.0/ICEfaces 2.0 it now appears as if the event listener called every time a page submit occurs regardless by which component the submit has been triggered (other text fields, drop downs, buttons), so I have to check the component ID inside the event listener.

Now if one has to check the component id inside the listener method, it is pretty much useless that the method has to be assigned in the facelet at the component level. I haven't seen this on my JSF 1.2/ICE 1.8.2 apps before.

Kind regards
Michael

SOLVED: the icepush.jar was missing in the WEB-INF/lib - after adding the icepush.jar, the ice:outputConnectionStatus component was functional.

Kind regards
Michael