At the moment we use the above combination, with the exception that we are still on JSF 2.1.
But I do miss the View Scope very strong in the CDI environment, I tried to update to JSF 2.2 while keeping the rest in place.
Now I encountered several problems with the javax.faces.view.ViewScoped. Views are dropped even if the ViewId didn't change, and other strange effects.
Now, I wonder if the choosen combination is valid at all. Does Weld 2.0 support JSF 2.2 and vice versa ?
Related
The legacy web app is using JSF1.2 with facelets. Due to the size of the app, upgrading it to JSF2 would take extensive effort. Is it possible to mix JSF1.2 and JSF2 in the same web app during the transition period?
I read this post: Mixing JSP and XHTML (Facelets) in JSF2 Project - possible?
but it seems to be related more to converting a JSP app to JSF2?
Thanks for any help.
Is it possible to mix JSF1.2 and JSF2 in the same web app during the transition period?
No.
You can mix JSP and Facelets in one web application, but you can definitely not mix different JSF impls/versions in the same web application. It would only result in class loading conflicts in all colors because multiple different versions of the very same classes are then present in the runtime classpath.
See also:
Migrating from JSF 1.2 to JSF 2.0
I have a Java EE app where I use JSF2 + PrettyFaces + EBJ3 + Glassfish
I just recently updated to Glassfish4 which is the default Server implementation for Java EE 7 and I started getting issues with PrettyFaces.
I have configured on my faces-config.xml:
<lifecycle>
<phase-listener>com.ocpsoft.pretty.faces.event.MultiPageMessagesSupport</phase-listener>
</lifecycle>
to enable for Faces Messages to be passed around correctly and displayed on screen.
But since I upgraded from Glassfish3 to 4 I started getting this issue:
java.lang.IllegalStateException: Cannot create a session after the response has
been committed
...
at com.ocpsoft.pretty.faces.util.FacesMessagesUtils.saveMessages(FacesMe
ssagesUtils.java:56)
at com.ocpsoft.pretty.faces.event.MultiPageMessagesSupport.afterPhase(Mu
ltiPageMessagesSupport.java:66)
If I remove the listener from faces-config.xml none of the Faces messages are displayed on screen.
I am using PrettyFaces to have nice well formatted URLs to enhance SEO on my site. I wish I couldn't have to replace it or refactor my app to not use it since I already mapped a lot of the navigation flow using it. Does somebody know a better option for this scenario?
I really appreciate any suggestions. Thanks.
I don't recommend to use MultiPageMessagesSupport if you are deploying to a "modern" container with JSF 2.2 support. The MultiPageMessagesSupport phase listener has been developed for JSF 1.x. JSF 2.x added support for persisting messages across redirects. Just execute this code before redirecting:
FacesContext.getCurrentInstance().getExternalContext().getFlash().setKeepMessages(true);
we have a lot of tests that uses Myfaces Test Framework for JSF 2.0.
http://myfaces.apache.org/test/index.html
Problem is we can't get it to work with JSF 2.1. Does anyone know a workaround or a way to solve this?
When we run the tests we get the following error: java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory
It works fine with jsf 2.0 though.
A typical use case in our code:
// code block;
assertFalse("Error message not expected. ", facesContext
.getMessages().hasNext());
JSF 2.1 has a few syntax changes so my guess would be that's the problem.
MyFaces Test 2.0 works with 2.0 and 2.1. In fact, MyFaces 2.1 uses myfaces-test20-1.0.4 as test dependency, and inside the code you can find a lot of tests using that library.
Based on advice posted here and here, I looked into and installed MyFaces CODI with my application. My biggest concern was overcoming the shortcomings of Weld's implementation of #ConversationScoped feature. After some hiccups I got it running on my GlassFish 3.1 development platform, and I converted all my beans to use
import org.apache.myfaces.extensions.cdi.core.api.scope.conversation.ConversationScoped;
In the end it seems like I am now not much further along than I was before. I do not have to call the conversation.begin() method anymore, which is good, but the beans hang around after the browser has left the page and come back.
What I was hoping for was the functionality of JSF 2.0 #ViewScoped that works with CDI. Once the user leaves the page, the backing bean should be discarded and re-created again if the user comes back. Is there a way to do this with CODI?
Incidentally, the documentation says it will pick up the #ViewScoped annotations and process them properly. I tried this and got and Weld wouldn't deploy it.
P.S. I am using myfaces-extcdi-dist-jsf20 version 0.9.5. I tried installing the core and JSF 2 optional module akibe but it would not deploy on my GlassFish/Weld platform. Any advice here much appreciated.
UPDATE 1: I ended up trying the ViewAccessScope annotation supported by CODI, and that seems to do what I wanted.
Follow-up question. The latest bundle that the maven repository that Apache maintains is 0.9.5 -- Can someone post the pom.xml segment that fetches the latest version?
Call conversation.close() before returning - ensure that you imported the correct annotation org.apache... and not javax... - see Wiki or use the ViewAccessScope instead. We are using: bundle in Glassfish 3.1.1 without problems. myfaces-extcdi-bundle-jsf20-1.0.1.jar is the only jar you need. Please also note that there is no "it". With CODI you have fine-grained groupable conversations instead of the monolithic and inflexible stuff you get with standard CDI conversations.
The set-up for the latest version with a Maven build is also in the Wiki.
I started web development using JSF, after studying JSP and Servlets for a while.
When you create a JSF web application you always(may be often but I am not sure if it always or not) have to create beans.xml and you don't write anything in it. But, if that file doesn't exist the JSF web app will not work.
What is the reason behind that?
Why we need that file?
Please, detailed explanation.
Adding to the answer of Micheal; CDI is not only useful in combination with JSF because of the injection support, but also because of its support to be used with EL (expression language). This is a feature JSF heavily depends upon.
In fact, CDI beans can almost entirely replace JSF managed beans and therefor you'll find lots of examples using them and a good amount of JSF books advising their use. For JSF applications CDI beans have e.g. the following advantages:
Can inject smaller scopes into larger scopes. E.g. request scoped GET parameters can be injected into a session scoped bean. This is not possible with JSF managed beans.
Can take advantage of the conversation scope; a scope that spawns multiple different pages.
Very unfortunate is that in JSF 2.0 and 2.1 the extremely handy view scope is not supported by CDI beans by default, although extensions like Seam can add these. (update: in JSF 2.2 there's a new view scope that does work with CDI beans)
All in all the confusion between JSF Managed beans and CDI beans is such that there's a JSF spec issue for this, see http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-976
The presence of a beans.xml file signals the servlet container that the application uses JSR-299 (Contexts and Dependency Injection) - without it, the application's classes will not be scanned for CDI annotations either and dependency injection will not be performed. If you don't use CDI (e.g. you only use plain JSF managed beans), you don't need beans.xml. If you do, you can use the file (instead of annotations) to define CDI configurations - this allows you, for example, to provide a test configuration where some dependencies are replaced with mocks.
From Getting Started with Contexts and Dependency Injection and JSF 2.x
When the application is deployed the server looks for CDI managed beans. In a Java EE 7 application, the classes on the path are scanned for CDI annotations by default. In a Java EE 6 application, the classes are scanned for CDI annotations if the module contains a beans.xml file.