I need to use fileUpload from Tomahawk because not provided by Jsf.
I want to know if Tomahawk is 100% compatible with Mojarra
I dont' find this information on the web.
My version of Mojarra (2.1.2) and tomahawk (1.1.11)
Thanks,
Yoel
There are three builds of Tomahawk 1.1.11: One for JSF 1.1, 1.2 and 2.0. As long as you use the 2.0 build of 1.1.11 you should be able to use it on Mojarra 2.1.x. The Tomahawk site clearly states all of this.
Edit:
As requested:
http://myfaces.apache.org/tomahawk-project/tomahawk/index.html
http://myfaces.apache.org/tomahawk-project/tomahawk12/index.html
http://myfaces.apache.org/tomahawk-project/tomahawk20/index.html
And then look at the download page, noting the different variants of Tomahawk 1.1.11 available for download: http://myfaces.apache.org/tomahawk/download.html
Related
I'm planning to convert a web app from using JSF managed bean to using CDI managed beans. I know I'll need to do below:
Add a empty beans.xml file in WEB-INF.
Replace all JSF #ManagedBean to CDI #Named annotations.
Replace all JSF scope annotations with CDI or OmniFaces scope annotations.
Replace all JSF #ManagedProperty with CDI #Inject annotations.
Is that all that needs to be done? Are there any gotchas that I need to be aware of?
Basically, that's indeed all you need to do provided that you're on a Java EE server already. When on Tomcat, you'd need to manually install CDI first. Instructions for both Weld and OpenWebBeans are detailed in the blog How to install CDI in Tomcat?
The below gotchas need to be taken care of:
While OmniFaces 2.x "officially" requires JSF 2.2, OmniFaces 2.0/2.1 is technically backwards compatible with JSF 2.1 and should in TomEE's case work on TomEE 1.x with JSF 2.1 as well, but OmniFaces 2.2 has a hard JSF 2.2 dependency (due to the new <o:viewAction> tag) and won't deploy on TomEE 1.x without upgrading its MyFaces JSF implementation to a 2.2 compatible version, or itself being upgraded to TomEE 7.x. See also OmniFaces Compatibility Matrix.
When you deploy an EAR with multiple WARs with each its own OmniFaces library, then generally all CDI functionality will work in only one WAR as the CDI context of a WAR-provided library is incorrectly interpreted as EAR-wide. This is an oversight in CDI spec and yet to be fixed in a future CDI version. See also OmniFaces Known Issues (CDI).
When you want to use OmniFaces-provided CDI injection support in #FacesConverter or #FacesValidator, and you're going to create/use a CDI 1.1 compatible beans.xml (and thus not a CDI 1.0 compatible one or an empty one), then you need to make sure that you have explicitly set bean-discovery-mode="all" in beans.xml. See also #FacesConverter showcase.
When replacing #ManagedBean(eager=true), be aware that standard CDI has no direct equivalent for this. You would use #Observes for this. OmniFaces offers #Eager annotation for the purpose. See also How to configure a start up managed bean?
When replacing #ManagedProperty in JSF 2.0/2.1/2.2, be aware that you can't inject #{param.xxx}, #{cookie.xxx} and #{initParam.xxx} directly via #Inject alone, while that was just possible via #ManagedProperty. OmniFaces offers respectively #Param, #Cookie and #ContextParam for the purpose. Only in JSF 2.3 there's a new #javax.faces.annotation.ManagedProperty annotation which can be used exactly the same way as original #javax.faces.bean.ManagedProperty which got deprecated since JSF 2.3.
I am using Primefaces 5.2 and when i use the captcha component, it renders the old API 1.0 captcha. If you look at Primefaces 5.2 showcase it renders the latest API 2.0 captcha. What could be the problem?
PrimeFaces latest community edition uses the 5.2 (i.e 5.2.0) version which implements the old captcha system from Google.
However, reCAPTCHA 2.0 has been introduced in 5.2.9 so you will have to wait for the next PrimeFaces 5.3 community edition (which is going to be released in "early fall" or in "mid-septembre 2015") or build and compile sources from the GitHub repository by yourself if you cannot wait.
Note (edited following Kukeltje's comment): PrimeFaces' version of the showcase is usually updated when there are new components or major improvements. Current showcase version is 5.2.10 bringing the new signature component.
See also:
https://github.com/primefaces/primefaces/issues/54
I have a java ee 6 project bundled as ear-file that contains two web war-archive. Both using Omnifaces. Today I upgrade Omnifaces to the newest version 1.6. But now I cannot deploy anymore. I got the following exception:
java.lang.IllegalArgumentException: Registering validator 'class org.omnifaces.validator.RequiredCheckboxValidator' failed, duplicates validator ID 'omnifaces.RequiredCheckboxValidator' of other validator 'class org.omnifaces.validator.RequiredCheckboxValidator'.
at org.omnifaces.cdi.validator.ValidatorExtension.processValidators(ValidatorExtension.java:73)
...
My Envroiment:
JBoss AS 7.1.1/ Omnifaces 1.6/ JSF Mojarra 2.1.26/ Primefaces 3.5
THX in advance.
This bug has been fixed in 1.6.1. There's quite a story behind this bug, so I just wrote a blog on that: CDI behaved unexpectedly in EAR, so OmniFaces 1.6.1 released!
Summarized: CDI context isn't WAR-wide, but EAR-wide. As to the particular exception you faced, it's because there was only one CDI ValidatorExtension being loaded from one WAR which is then applied EAR-wide and thus processing all #FacesValidator classes from both WARs instead of the WAR where the CDI extension was being loaded from.
Note that this is not a problem in OmniFaces. This is a problem in the way how CDI works in EARs.
I have a JSF 2.0 application. Can we use acegi-jsf of version 1.1.3. Can we use this tag library for JSF 2.0.
Acegi does not exist anymore. It was taken over by Spring in April 2008 and continued under the brand "Spring Security". That Acegi tag library is likely JSP targeted and not Facelets targeted. JSF 2.0 was namely introduced in December 2009, which is a long time after the Acegi takeover by Spring.
You should be looking for Spring Security JSF 2.0 tag library instead. However, a "JSF 2.0 tag library" can better be rephrased to "Facelets tag library" in order to end up with a more correct term and thus get better Google hits. You ultimately want to use this on Facelets (XHTML) files, right?
I don't do Spring, but Googling on "Spring Security Facelets tag library" yields among others this link which describes how to manually declare Facelets tag libraries and EL functions. There does thus not seem to be a full integration (i.e. just dropping JAR in webapp without the need to manually create .taglib.xml files), they seem to be working on that for future releases.
Is struts2-jquery-tree.plugin.jar compatible with struts1.3? Will the plugin be enabled by default?
No it is not compatible. You need Struts2 2.1.x or higher to use the Struts2 jQuery Plugin.