Closed GoogleCodeExporter closed 9 years ago
We've never faced this kind of problem, at least not with standard JSF nor
PrimeFaces.
The only known issue with Html5RenderKit is that HTML5 specific input types
will fail in all browsers when using <f:ajax> on Mojarra versions until with
2.1.13.
When I have time, I will look closer at it using the specified JSF/RichFaces
version.
Original comment by balusc
on 28 May 2013 at 12:21
Rudie, thanks for your report.
One small comment, even though both Bauke and me are Dutch and can read your
code perfectly well, this is an project for international users and for
everyone who doesn't speak Dutch the source you posted will look like
gibberish. If possible, please translate example code to English whenever you
post it on places like this. Thanks! ;)
Original comment by arjan.tijms
on 28 May 2013 at 9:34
Hi,
For your information, i made a simple test project using the richfaces maven
archetype where you can reproduce the issue. If you want me to upload it
somewhere, please let me know.
I was testing on an old version of firefox. After upgrading to the latest
version (21.0), it fails on firefox as well.
Tested with omnifaces:
IE 8.0 : OK.
Firefox 21.0: fails
Chrome 27.0: fails
Tested without omnifaces:
IE 8.0 : OK.
Firefox 21.0: OK
Chrome 27.0: OK
Original comment by ekkelenk...@gmail.com
on 29 May 2013 at 8:32
One more thing I noticed, the issue only appears when actually using a HTML 5
tag.
After removing the type="search" attribute with omnifaces enabled, the h:input
text is actually bound to the backing bean.
Looks like the a4j:commandLink has the same issue as f:ajax ?
In the posted example I see the type="search" is missing. This should be added
to reproduce the isse.
Original comment by ekkelenk...@gmail.com
on 29 May 2013 at 10:01
[deleted comment]
Yes, definitely upgrade Mojarra to at least 2.1.14.
As this problem is not related to OmniFaces, I'll close the ticket as Invalid.
This issue is mentioned in the known issues list
https://code.google.com/p/omnifaces/wiki/KnownIssues
Original comment by balusc
on 29 May 2013 at 10:39
Hi,
Too bad. In JBoss EAP6 you cannot upgrade to a higher version of Mojarra. You
have to use 2.1.7.
Are you sure it is the same issue as the f:ajax issue? Since it does work in
IE8....
Original comment by ekkelenk...@gmail.com
on 29 May 2013 at 11:18
You can definitely upgrade Mojarra in EAP6. We're currently running 2.1.22 in
EAP6.0.1 for zeef.com.
As to IE8 (and the older Firefox), they simply do not support HTML5 inputs. The
input type="search" is just been interpreted as input type="text" in HTML DOM.
Original comment by balusc
on 29 May 2013 at 11:41
Thanks for your feedback!
I'm really interested to know how you managed to get a higher mojarra version
in EAP 6? We're still running EAP 6.0. It packages 2.1.7 as default and
packaging a Mojarra version in de war fails. Has this been fixed in the EAP
6.0.1 version?
Thanx in advance,
Rudie.
Original comment by ekkelenk...@gmail.com
on 29 May 2013 at 11:51
Packaging Mojarra in WAR indeed fails. You need to upgrade it in JBoss itself.
- Download Mojarra 2.1.22 API and impl files:
- https://maven.java.net/content/repositories/releases/com/sun/faces/jsf-api/2.1.22/jsf-api-2.1.22.jar
- https://maven.java.net/content/repositories/releases/com/sun/faces/jsf-impl/2.1.22/jsf-impl-2.1.22.jar
- Make sure that JBoss is shutdown.
- Update JSF API in /modules/javax/faces/api/main:
- Delete or backup the old JAR file.
- Delete the old .index file (JBoss will autocreate one).
- Put jsf-api-2.1.22.jar file in there.
- Edit module.xml file:
- If absent, add <module name="com.sun.jsf-impl"/> to <dependencies>
- Edit <resource-root> to specify the new file name <resource-root path="jsf-api-2.1.22.jar"/>
- Update JSF impl in /modules/com/sun/jsf-impl/main:
- Delete or backup the old JAR file.
- Delete the old .index file (JBoss will autocreate one).
- Put jsf-impl-2.1.22.jar file in there.
- Edit module.xml file:
- Edit <resource-root> to specify the new file name <resource-root path="jsf-impl-2.1.22.jar"/>
- Cleanup JBoss cache/work data just to make sure that there's nothing hanging
and colliding:
- Trash all contents of /standalone/data (expect of custom data folders like folder containing uploaded files)
- Trash all contents of /standalone/deployments
- Trash all contents of /standalone/tmp
Original comment by balusc
on 29 May 2013 at 11:56
Thanks a lot! I'm gonna give that a try.
Much appreciated!
Original comment by ekkelenk...@gmail.com
on 29 May 2013 at 12:02
Original issue reported on code.google.com by
ekkelenk...@gmail.com
on 28 May 2013 at 8:20