What needs to be change when migrationg from jsf 1.x to jsf 2.x , richafaces 3.x to 4.x - jsf
I am new to jsf.
I am working on migration project.
In this I need to migrate from jsf1.2 to 2.1
and richfaces as well..
In general what I need to change?
I have one more requirement that navigation rules must be quoted explicitly in faces-config.xml?
How to write these rules in faces-config.xml?
Thanks in Advance
First you should understand that this is a painfull to migrate from JSF 1.x to jsf 2.x but it is even more painfull to migrate from Richfaces 3 to Richfaces 4.
JSF 1.x to 2.x upgrade can be done independently from Richface upgrade. So I would recommend you first update JSF and check that everything is working and only after that try updating Richfaces. Look at this question about JSF migration for more info. Or just google it. There is a lot of info about it.
Richfaces 3 to 4 migration is very very painfull because JSF 2 introduced it's own ajax and you will need to change a lot of attributes all overt the project. But the biggest pain is that Richfaces 3 work much more stable than Richfaces 4. Richfaces 4 is very buggy. I can list some bugs that I encountered and some solutions for them.
rich:autocomplete is very buggy. Not sure if it is fixed already
but when I tried using it it was not working with Spring in
composite views(<ui:include pages). After I sumbitted bug report
they seem to do something there but not sure if this works now. I
didn't check. https://issues.jboss.org/browse/RF-11469
I would advise you to replace this component with simple jQuery UI
autocomplete component with some spring mvc controller on backend.
rich:tabPanel is very buggy. Separate tabs do not have action
attribute any more. This was breaking functionality with initing tab
contents when the tab was opened with ajax. Immediate attribute also
not working for tabs. Here is the issue on jboss jira: https://issues.jboss.org/browse/RF-11417 workaround is really stupid.
I just went into source code of richfaces and made it working.
Exception handling is very buggy. Seems that exceptions are just
swallowed in many places in richfaces source on ajax requests so you
can not handle them the right way.
I went again into Richfaces code and removed exception swallowing by
throwing out exceptions.
rich:fileUpload component can work and can not work for you. You
can get request prolog can not be read exception in some
cases(This is what I was getting). And This is connected with new
app server feature of reading multipart request into
request.getParts(). And Richfaces do not handle such situation and
error out because inputstream of multipart request is already read
fully.
I again went to source code of Richfaces and added catch for
situation when request.getParts is not empty. I even created an
issue on Jboss but guys said this works on new Jboss server that's
why it is not an issue(I use tomcat). https://issues.jboss.org/browse/RF-13061 the issue is close still it is not working on tomcat.
A lot of issues on client side. By default multiple forms will not
work on your pages like they were working in jsf 1.2 and richfaces 3
because the viewstate id is not updated where and when it needs to
be.
To fix this you will need to add additional script. It is described
in the answer to this question
Also on the client side you should know that if in the response of
any ajax request you will have some js that will fail everything
stops working. You can not have js errors inside xhtml. The page
will freeze completelly. Also it is tricky to have CDATA tags on
the xhtml pages. They can also fail.
Richfaces messages work the way that sometimes they show up and
sometimes not. They are ajax rendered but seems that they can break
the page. Ajax reposnse can have an update that should update
messages that is not rendered on the page and when it will not find
this message in your html it will stop rendering everything that is
left to update. As a result your links and buttons will not rerender
anything in some cases.
Here evaluating limitRenderattribute helps a lot.
It is a short list. There probably a lot more to be aware of and that you will see after update =)) Richfaces 4 are still buggy.
Related
Can Bootsfaces be used with Richfaces?
I have a web application with the following: JSF 2.2.6 Java 1.7 Tomcat 8 Richfaces 4.5.7 Omnifaces 2.2 I would like to enhance the look and feel of the web app to use Bootsfaces. I have added Bootsfaces jar to my project (via .ivy) and rebuilt. Before even updating the first web page to use Bootsfaces in the project I wanted to see if there were any conflicts after adding the Bootsfaces jar. It seems there is. I am getting the following errors shown in Firebug: ReferenceError: jsf is not defined TypeError: RichFaces.ui is undefined Does anyone know whether Bootsfaces works with Richfaces and if so could they kindly provide a link with migration steps to follow?
Currently, we, the BootsFaces team, do not support RichFaces. We strive for compatibility with PrimeFaces, OmniFaces, AngularFaces and - if possible - ButterFaces. Neither RichFaces nor ICEFaces are on our list. However, if someone were to join our team in order to support RichFaces, they'd certainly be welcome!
Primefaces 2.2.1 with FileUpload from Primefaces 3.0
Related to the last comment on this question, i would like to know if anyone managed to use the HTML5-Fileupload of Primefaces 3.0 with an older Primefaces version. We have a lot of trouble with the old flash-version of the fileupload. I know that the best option would be to update the whole project to the new primefaces version but it´s not possible for this project.
This is not going to be trivial. That you're already asking this question already indicates that it's going to be a long journey. I'd rather use a barebones and to-the-point file upload component of another component library such as Tomahawk's <t:inputFileUpload>. It only doesn't support asynchronous uploading and you need to make the submit button of the form a non-ajax one, but it does the job you want it to do without much hassle. You can find in this answer detailed step-by-step instructions how to integrate and use it in your project: JSF 2.0 File upload. In case of PrimeFaces, you only need to make sure that you have removed PrimeFaces' own file upload filter from the web.xml, otherwise it would consume the uploaded file before Tomahawk's own filter get the chance.
Thats very difficult, I have many problems with fileupload and finally migate to 3.0 but witch are problems?. If you wanna to change fileupload you will can change source code in library is not very smarted if you desnt know jquery ui o you can use other framework or use directly. http://www.matlus.com/html5-file-upload-with-progress/ good luck
Richfaces 4.1 with JSF 2.1.7: resources are all in the body instead of head of the html document
I was wondering if anyone has experienced a similar problem. I just tried upgrading to JBoss AS 7.1.1 which comes prepackaged with JSF 2.1.7. Before I was using JSF 2.0.4 and everything was fine with RichFaces (btw I am using 4.1.0.Final in both scenarios). Now with Mojarra 2.1.7, it seems that all my Richfaces resources such as javax.faces.resource/richfaces.js.seam and javax.faces.resource/richfaces-event.js.seam are being included in the body of the rendered html page instead of the head. I am getting a lot of Richfaces is not defined errors because I am trying to use js richfaces methods elsewhere in my code. It just won't work since all the richfaces js files are loaded in the body. I have tried researching this issue online and I can't find any info on it. I have an h:head tag in my document so that isn't the issue. Any help would be appreciated. Thanks.
ICEfaces 2.0 and h:commandButton method not called, with ice:commandButton everything is ok
I'm trying to use ace:fileEntry to upload a picture, as I read this component requires a submit from h:commandButton in order to start downloading. My problem is that when I switched my ice:commandButton with h:, my managed bean (which is in Conversation Scope) gets created again (#PostConstruct called) and the method in h:commandButton and also the fileEntryListener aren't called anymore. And as another problem that might be causing this is that when I first enter my page the managed bean gets created and I call conversation begin, but when I do a second request (from a commandLink) the managed bean is created again, and a new conversation is started, after that you can play how long do you want the managed bean doesn't get created again. Back to my initial question, if I have ice:commandButton the managed bean ins't created again, if it's with h: it gets created again. And to add a little bit more fun in it, if I remove the rendered attribute (which resolves to true) from ace:fileEntry the fileEntryListener is called, but the action from h:commandButton isn't called no matter what. I tried to add explicit ids to the components, tried to change ice:form with h:form .. nothing. Please Help. Ps: why ICEfaces 2 can't work with all ice components, why does it requires h:commandButton, instead of ice:commandButton, why the new JSF 2.0 stuff with f:selectItems backed by a regular list isn't working with ice:selectOneMenu, works just with h:selectOneMenu ? What's up with ICEfaces ? And why CDI doesn't work as expected, with Seam 2 also I had problems with conversations called twice .. ps2: if I don't navigate to another view ?cid=1 isn't present in the URL.
Now, with ace:fileEntry and h:commandButton, the reason why the ice:commandButton can not be used is because that is an AJAX component, and browsers will not upload files in an AJAX submit. Even with HTML5 it is not automatic, and new File and XmlHttpRequest APIs must be used. In an HTML4 browser, only a full page, full form, submit will upload the file contents, and only h:commandButton operates that way. For more details, you can see this explained near the top of the page at: http://wiki.icefaces.org/display/ICE/FileEntry With our ice: components, which are extended variants of the h: components, such as ice:selectOneMenu, they are lacking some new JSF 2 features because we have been focusing on our newer Advanced Component Environment, due to customer demand for rich client-side components. As well, the focus was on maintaining backwards compatibility with the ice: components, to ease customer migration from ICEfaces 1.8.x to ICEfaces 2.x, and less so to be altering those components' behaviours. But we are still actively maintaining and improving the ice: components, and will be adding the new features soon. Feel free to create any enhancement requests in our Jira system, and to vote on any existing entries, as this does guide our development priorities. http://jira.icefaces.org/ Mark Collette
I'm Mark Collette from the ICEfaces component team, and hopefully I can answer some of your questions. Most of your issues seem more related to CDI integration than problems with the components themselves. I know that the symptoms change depending on which component you use, but I think that's because the ice: components use AJAX and the h: components do not. Many times integration issues with other frameworks are more observable in AJAX interactions than in full page GET/POST interactions. So your issues may be due to either our CDI integration, or your application's configuration. So please review our documentation on using ICEfaces with CDI, and if you you still experience any issues, I recommend posting the details to our forums. http://wiki.icefaces.org/display/ICE/Using+ICEfaces+with+CDI http://www.icefaces.org/JForum/forums/list.page [Sorry, but this forum is not letting me post more than 2 links, so I'll split the rest of my message into another post, and hopefully that will work] Mark Collette
Can I Turn Off Implicit Navigation in Jsf 2.0?
I'm migrating old projects from JSF 1.2 to JSF 2.0. The projects are JSP based. I'm having trouble with implicit navigation after the migration. The action methods that return values (Let's say, for internal use) cause JSF to try to navigate to non existing pages. For example, a method that return "Error" will make the browser try to access /Error.jsp which will result in a 404. I would like, for these projects, to turn off implicit navigation. Is that possible? Thanks!
No, that's not possible. It's however planned for JSF 2.2, see also JSF spec issue 937. What is it, the internal use for which you're trying to (ab?)use navigation outcomes? Exception handling? You might want to throw a normal exception instead and handle it the usual way.