What are the major differences between primefaces version 3.5.x and 4.x besides the obvious java-ee-7 compliance in the 4.x versions? Has version 4.x been rewritten internally? If so what are the differences? I am currently using primefaces 3.5.20, so many of the new or updated components are already available. Has there been any work to streamline ajax throughput?
There are many improvements:
The main one is the integration with jsf-2.2 specification. As JSF 2.2 is servlet 3.x compatible, the file upload system has changed in order to take advantage of servlet 3.x features and make it in html 5 way. It also includes support for HTML pass through attributes, included at JSF 2.2 and able to include non-JSF attributes at the rendered page.
Client Side Validation Framework: I still have to try that, but one of the lacks of vanilla-plain JSF is the absence of client side validation. JSF is known for being a server side framework. However, sometimes client validation is also convenient in order to bring the end user a greater experience. Primefaces 4 is supposed to include that (in fact they've been working to adapt their aproach to HTML5 standards).
Search expressions: Something in JSF that can puzzle you is searching the component ids at client side. JSF uses its own preffixed identifiers, so sometimes it is difficult to search for what you want. JSF 2.2 provides a set of keywords: "#this", "#form", "#all", "#none", in order to simplify what you want to make a reference to. In primefaces 4 apart from that, you've got #composite which resolves the closest CompositeComponent parent, #widgetVar(name) which resolves a component by its widgetVar and #child(index) which resolves the nth child.
Lots of bug fixes and component improvements, some of them have been done in parallel with 3.5.x series.
About ajax perfomance, I know there have been some issues in concrete cases, but apart from fixing them and adding new capabilities to their jquery-ajax utilities, I'm not aware about more improvements.
See also:
Primefaces 4 improvements
Default text (placeholder) in InputText component
Search expressions in PrimeFaces 4
Related
It seems that JSF 2.0 does not call "class level constraints". Quoting from an SO answer
JSF 2.0 doesn't call class level validation constraints. From JSF validation: JSF 2 provides built-in integration with JSR-303 constraints. When you are using bean validation in your application, JSF automatically uses the constraints for beans that are referenced by UIInput values.
The answer furthermore suggests using SeamFaces to validate the class-level constraints anyways.
Unfortunately this is a non-option, since it introduces a somewhat massive dependency for just validating what should be validated anyways.
My question thus is:
How can I get JSF to validate class-level constraints?
Manual validation in the controller is tedious and a lot of repeated code, and thus an option I would like to avoid.
I have attempted to do this by annotating the Controller-Field to be validated with #Valid, which didn't help.
I guess it should be possible to either make the "Process Validations" phase do that for me or hook in something akin to a Filter after the "Update Model Values" phase, that would centrally run the model values through a Validation.
Until the upcoming JSF 2.3, JSF doesn't support class level validation using a.o. #Valid. This is an eternal issue, given that the very first JSF spec issue ever addresses this.
Your resort is either using a 3rd party library which has already taken care of it, or homebrewing it based on sources of the open source library in question (taking licensing into account).
Apart from SeamFaces <s:validateForm> which you already found, there's also OmniFaces <o:validateBean>. The major difference as compared to <s:validateForm> is that it doesn't use a JSF Validator, but a JSR303 ConstraintValidator (and that you've the whole entity immediately at hands without the need to declare and annotate a bunch of fields, repeating the entity's properties.
JSF 2.3 support will come in flavor of <f:validateWholeBean> which is largely based on OmniFaces <o:validateBean>.
We have projects using Struts 2.0 and 2.1.
We're using web-hosting with Tomcat and both projects are working fine on remote servers. Recently, we got warning message from the webhosting provider, like:
This notice is inform you that recently numerous vulnerabilities have been discovered related to Struts and Struts2 frameworks and other frameworks which use OGNL classes.
Since your application is using Struts or Struts2 framework, we HIGHLY recommend that you URGENTLY update it to the most recent version: Struts v2.3.16.1
After research, we found there're consistent upgrades:
http://struts.apache.org/announce.html
Therefore, we tried to upgrade our Struts2 to 2.3.16.3 (latest version at present). However, we found it's not a trivial task to upgrade Struts2, since everything doesn't work, including AJAX tags, AJX form submit, auto-complete, etc. In this sense, Struts 2 is not well designed for scalability.
One example is that whenever we submit our AJAX form, the result will be in a new page instead of in the targets field defined in the sx:submit or sj:submit tag. We don't want to re-write all the codes just because of the upgrade.
We want to know if we don't upgrade Struts2 to the latest version, what kind of vulnerabilities our web application will face. Could anyone give us more details or any hint for solutions based on our situation? Thanks so much.
You are probably looking for Security Bulletins. Each documents describe the summary, problem, and solution to resolve the problem. At the end of each document you can find hotfixes if they are available.
One example is that whenever we submit our ajax form, the result will
be in a new page instead of in the targets field defined in the
sx:submit or sj:submit tag.
It seems you are using struts2 and struts 2 jquery plugin, so try to update to struts 2 jquery 3.7.0 too.
I recommend to accept some reworks and upgrade as some security issues are high.
There are some key parts which has changed and may need to be considered during upgrade like acceptableParameterName. Also review your param interceptor stack and list of exclude parameters.
I moved a JSF application from Galssfish 3.1.2 to Glassfish 4.0 and I thought the new server release was completely back compatible.
I found out it is not.
I used an outdated library, Primefaces 2.X, and some components stopped working properly, at least <p:tabview>. Common sense suggests to pass to a newer library such as Primafaces 3.5, but that way I have to modify my xhtml pages. Cannot find a compatibility matrix anywhere, nor a migration tutorial. Can you help ?
There is at least another weird problem outside those related to the Primefaces library.
I have a quite complex page and till now I couldn't isolate the problem to a simpler scenario.
In this page I have an <ui:repeat> tag and then a form with a button.
The button is configured to send Ajax request and update (render) only a single ui component.
At the 3rd Ajax request it stops working and I get an error saying there is a duplicate ID corresponding to the <ui:repeat> tag.
Any idea ?
Is there a migration guide from Glassfish 3.1.2 to Glassfish 4.0 which gives hints on what has changed and how to modify existing applications ?
Update
I found the following post which deals about the last problem I'm talkin about
Component ID xxx has already been found in the view.
Unfortunately I cannot understand how to solve it despite it has an accepted answer !
This is one of the many bugs that were released with GF4.
I would suggest either waiting for the next release of GF (if you need a released version) or update GF to the latest JSF release (Currently 2.2.8 I think).
JSF implementation jars
JEE7 APIs
JSF current and older bugs
Our application is having issue with rendering time on various part. We have been able to pin point the performance issue with a profiler (YourKit Java Profiler) within the JSF restoreView phase (lifecycle). Since, we use a lot of components in some pages the rendering of the tree must be the source of the problem. Some question on stackoverflow looks pretty much like what we are dealing. Also, we can see the same slow speed in dev and production.
Some specs:
MyFaces 2.1.7
javax.el 2.1.0
Profiler (CTRL+SCROLL to see details):
We are trying to find solutions. So far, we came up with those:
Use less composition/components (which is not that great, because we liked to make generic component).
We could also go into JSF stateless mode.
Find the actual problem with JSF (IN DEEP).
Recently, we found out that some JUEL library (expression language) could greatly increase the rendering time.
I've been dealing with making JUEL works with Spring 3 (with OSGI). Here's the spec:
JUEL 2.1.3.1 bundle (note: this bundle use a different version of javax.el than the one I use in my application will that cause clash?)
I have found another maven repo which only does Juel Implementation and a more recent version.
Update:
Found a solution for javax.el clashing, since there was a lot of problems in the juel-api (because it's export his own javax.el) I modified the manifest with that line Fragment-Host: javax.el to eliminate it.
Is there a configuration/set up to enable better performance?
Or, how to you actually configure JUEL with MyFaces and Spring?
I would say that the problem is caused by Spring Web Flow. I remember this issue SWF-1540. First check if you are using the right version (2.4.0.M1 or upper). Note personally I have not tested if that configuration has a performance issue, but I can say that MyFaces 2.1.7 an upper versions does not have any issues. It is known that some EL versions has perf issues, so try with juel or with apache EL (jasper-el, bundled with Tomcat).
As a personal opinion, watch out for Spring proxies, it is known that in some cases, when the pages are very big and complex, the proxies has a significant impact over performance. The suggested solution is use Apache OpenWebbeans, which is a very fast CDI implementation, optimized for those cases when you have a lot of beans interconnected.
You can check this article too "Understanding JSF 2 and Wicket: Performance Comparison" for tips about MyFaces performance.
You have to try by yourself what will work for your case, but I hope with these advices you can focus better your search.
I am currently studying Java EE with Hibernate for a project. In The Web App I am creating I am planning to Ajaxify page contents, and Site wide audio player(Which I think would be implemented using AJAX).
I am using a JSP based MVC, no frameworks, Just Java EE and Hibernate. And I've heard that I need to use a Framework like JSF to be able to AJaxify may web-app. How true is this? Do I really need to learn JSF or other frameworks to be able to Ajaxify my web app? As much as possible I do not want to learn a new framework for now since it is a big learning curve. but if there's no other way to Ajaxify my web app, I'll study a framework.
You don't have to adopt any framework to use partial page updates and similar, you can construct and send requests "manually" with JavaScript, but this is much more tedious then using a framework like JSF, maybe coupled with a component library like primefaces.
EDIT: you can find an abundance of examples of ajax capabilities in the primefaces showcase. Primefaces uses JQuery internally.
EDIT2: I have found some resources on how to dispatch ajax requests with JQuery from a JSP page (I assumed that using JSP was almost equal to not using a framework ;)): here and here. I hope this is what you were looking for.
To add on #Kostja's answer -
I totally agree with him, with Ajax you just need to have a servlet to handle the HTTP requests, and proper JavaScript code.
Besides JSF,I would also consider to look at Apache Wicket - you can read here how Wicket handles Ajax.
The reason I'm suggesting Wicket is that it's more comfortable to some developers to work with somewhat more "component oriented" (swing-like) framework.