I read somewhere that it's better to use CDI #Named instead of JSF #ManagedBean, because of CDI, so I'm trying to convert some of my code.
I'm trying to use #Named in JSF, but it's always unreachable.
When using #ManagedBean there was no problem.
I'm using it like #ManagedBean, as below
CustomerBacking.java
package com.wordpress.marczykm.backing;
import javax.ejb.EJB;
import javax.enterprise.context.RequestScoped;
import javax.inject.Named;
#Named("customer")
#RequestScoped
public class CustomerBacking {
#EJB
private CustomerService customerService;
public CustomerBacking() {
}
public String addCustomer(Customer customer) {
customerService.addCustomer(customer);
return "customer_overview";
}
public Customer getCustomer(){
return customerService.getCustomer();
}
}
index.xhtml
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">
<h:head>
<title>EJB 3.0 Test</title>
</h:head>
<h:body>
<h:outputText value="#{customer.firstname}"/>
<h:form>
<h:outputText value="Imię"/>
<h:inputText id="firstname" name="firstname" value="#{customer.firstname}" /><br/>
<h:outputText value="Nazwisko"/>
<h:inputText id="lastname" name="lastname" value="#{customer.lastname}" /><br/>
<h:commandButton value="Dodaj" actionListener="#{customer.addCustomer}"/>
</h:form>
</h:body>
</html>
To sum up, looking at Netbeans sample CDI app, the bean which needs to be accesible by JSF page needs to:
have #Named annotation (javax.inject.Named)
have scope annotation (like #SessionScoped, #RequestScoped, #ViewScoped), but imported from javax.enterprise.context.*
doesn't have to have empty, non-argument constructor
and the thing that wasn't in my code is that, that the bean needs to implement Serializable (java.io.Serializable)
last thing is that if your app is a web application it needs a beans.xml (can be completly empty) in WEB-INF directory, if it is a bean app it have to be in META-INF directory
You don't mention which servlet container/application server and which CDI implementation version you're using.
I have no clue what Spring Tool Suite assumes as default, presumably it's Tomcat, Spring and no CDI at all, so you have to add and configure a CDI implementation (e.g. Weld or OpenWebBeans).
For CDI 1.0, you'll have to add a WEB-INF/beans.xml descriptor (which may be empty) to have your beans discovered. This is no longer necesary for CDI 1.1.
Related
I'm trying to do a kind of simple customizable news view page into my web application, like Google's one but much simpler, with frames. Each frame object simply has his title and an url to be added as its content.
I'm using JSF and primefaces, both on their newest versions. So my backing bean, which is #ViewScoped, has access to the logged user, which is stored in a #SessionScoped bean, and that user has his corresponding frames loaded.
Problem comes when I try to iterate it over the #ViewScoped bean, because the only way I find to do it is with a c:forEach tag. That's the way I do:
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:p="http://primefaces.org/ui"
xmlns:fn="http://java.sun.com/jsp/jstl/functions">
<h:form>
<p:panel header="Noticias">
<h:panelGrid columns="#{fn:length(navegableHomeManager._UserFrames)}"
width="100%">
<c:forEach var="frame" items="#{navegableHomeManager._UserFrames}">
<p:column>
<p:panel header="#{frame._Name}" closable="true"
style="width:95%;height:500px;" id="#{frame._Name}">
<p:ajax event="close"
listener="#{navegableHomeManager.actionFrameClosed}" />
<ui:include src="#{frame._Path}" />
</p:panel>
</p:column>
</c:forEach>
</h:panelGrid>
</p:panel>
</h:form>
That iteration obviusly does not work with navegableHomeManager bean because it is #ViewScoped. So the bean will be rebuilt in each of the iterations. The solution I've reached uses another #SessionScoped bean between the navegableHomeManager and the loggedBean, so that way the frames are stored there and I can have access to them properly into the iteration. That's working with the code above.
However I don't think it should be compulsory to use a #SessionScoped bean (creating an specific bean for every single case) every time I want to iterate in that way. That's why I have tried using components to avoid the iteration.
<p:dataGrid columns="#{fn:length(navegableHomeManager._UserFrames)}"
value="#{navegableHomeManager._UserFrames}" var="frame">
<p:column>
<p:panel header="#{frame._Name}" closable="true"
style="width:95%;height:500px;">
<p:ajax event="close"
listener="#{navegableHomeManager.actionFrameClosed}" />
<ui:include src="#{frame._Path}" />
</p:panel>
</p:column>
</p:dataGrid>
It doesn't work neither when the bean is #ViewScoped or #SessionScoped, because even the frames properties are set, the ui:include tag has already been built with no destination path, so I can't render the destination path dinamically. I think that, as ui:include is being applied at the same time as c:forEach, using a c:forEach tag is really the only way to go through this.
Pool your ideas.
UPDATE
Here I post more xhtml code to help in the understanding of the context. The new's page is integrated into a template. That's the page which is targeted (/system/home/index.xhtml):
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
template="/templates/general_template.xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:c="http://java.sun.com/jsp/jstl/core">
<ui:define name="metadata">
<f:event type="preRenderView"
listener="#{navegableHomeManager.initialize}" />
</ui:define>
<ui:define name="general_content">
<ui:include src="/system/home/home_view.xhtml" />
</ui:define>
And that's the way I also tried to do it, but not making the c:forEach tag to work:
<context-param>
<param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
<param-value>/system/home/index.xhtml</param-value>
</context-param>
And that's the backing bean header:
#ManagedBean
#ViewScoped
#URLMapping(id = "home", pattern = "/home", viewId = "/system/home/index.xhtml")
public class NavegableHomeManager extends SystemNavegable {
/**
*
*/
private static final long serialVersionUID = 6239319842919211716L;
#ManagedProperty(value = "#{loggedBean}")
private LoggedBean _LoggedBean;
//More stuff
Stick to <c:forEach>. It does the job you're looking for. The <ui:include> runs during view build time, so the iteration tag should also run during view build time.
As to the #ViewScoped bean problem, you've 2 options:
Turn off partial state saving for the particular view:
<context-param>
<param-name>javax.faces.FULL_STATE_SAVING_VIEW_IDS</param-name>
<param-value>/news.xhtml</param-value>
</context-param>
Change it to a #RequestScoped bean and use <f:param> and #ManagedProperty to maintain state across postbacks by request parameters.
There would be a third option if JSF 2.2 is available: just upgrade to JSF 2.2. They've fixed the chicken-egg problem in view scoped beans and partial state saving.
I use JSF 2.0, hibernate-validator4.2.jar validation-api.jar tomcat and Eclipse.
I put #Size(min=3, message="xxx") annotation in a #ManagedBean and <f:validateBean /> between <h:inputText value="#{user.name}"></h:inputText>
When I try to run the project i get this error...
exception
javax.servlet.ServletException: Expression Error: Named Object: javax.faces.Bean not found.
javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
root cause
javax.faces.FacesException: Expression Error: Named Object: javax.faces.Bean not found.
com.sun.faces.application.ApplicationImpl.createValidator(ApplicationImpl.java:1593)
com.sun.faces.facelets.tag.jsf.ValidatorTagHandlerDelegateImpl.createValidator(ValidatorTagHandlerDelegateImpl.java:244)
com.sun.faces.facelets.tag.jsf.ValidatorTagHandlerDelegateImpl.applyAttachedObject(ValidatorTagHandlerDelegateImpl.java:132)
com.sun.faces.facelets.tag.jsf.ValidatorTagHandlerDelegateImpl.applyNested(ValidatorTagHandlerDelegateImpl.java:211)
com.sun.faces.facelets.tag.jsf.ValidatorTagHandlerDelegateImpl.apply(ValidatorTagHandlerDelegateImpl.java:87)
javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
why? (this only appears when i put tag)
User.java
import java.io.Serializable;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.validation.constraints.Size;
#ManagedBean(name="user")
#SessionScoped
public class User{
#Size(min=3, message="At least 3 characters!")
private String name;
public String getName() {
return nume;
}
public void setName(String name){
this.name=name;
}
}
adduser.xhtml
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core">
<ui:composition template="/templates/master_layout.xhtml">
<ui:define name="text_header" >Panou de control: Adauga user </ui:define>
<ui:define name="content">
<h:panelGrid columns="3">
<h:outputText value="Name"></h:outputText>
<h:inputText value="#{user.name}">
<f:validateBean />
</h:inputText>
<h:commandButton value="Inregistreaza" action="index.xhtml"></h:commandButton>
</h:panelGrid>
</ui:define>
</ui:composition>
</html>
It should work perfectly fine, although the empty <f:validateBean/> tag is entirely superfluous in this context. It's supposed to be used to "finetune" validation more, such as grouping of validation and/or disabling the implicit bean validation on a per-input basis by specifying the desired tag attributes. You have however no attributes on that tag, so just remove that tag altogether. On a default JSF 2 + JSR 303 project setup, it's supposed to kick in fully transparently without adding more JSF tags whenever there's a JSR 303 annotation on the property such as #Size and likes.
But I don't think that removing the tag will solve this particular exception. Your problem lies thus deeper. This validator is supposed to be auto-registered on startup. However, the exception basically tells that the validator is not registered at all. With the information given so far, it's not possible to give a targeted answer. I can think of the following possible causes:
There's a bug in the JSF implementation which you're using. Upgrade it to a newer version.
You have multiple JSF libraries of different versions in your classpath. Cleanup it.
The faces-config.xml root declaration is not declared conform JSF 2.x. Fix it.
My problem is that one of my ViewScoped bean is created several time within the same view. The constructor of ViewScopedBean is created every time I select a node in the tree.
<h:form>
<p:tree value="#{treeBean.root}" var="node"
selectionMode="single" selection="#{viewScopedBean.selectedNode}">
<p:ajax event="select" update="selectedNode, treeBeanUpdate, otherBeanUpdate, panel" listener="#{treeBean.onNodeSelect}" />
<p:treeNode>
<h:outputText value="#{node}" />
</p:treeNode>
</p:tree>
Selected Node: <h:outputText value="#{viewScopedBean.selectedNode}" id="selectedNode"/><br/>
Current TreeBean: <h:outputText value="#{treeBean}" id="treeBeanUpdate"/><br/>
Current OtherBean: <h:outputText value="#{viewScopedBean}" id="otherBeanUpdate"/><br/>
<p:outputPanel id="panel">
<ag:profileComponent managedBean="#{viewScopedBean.profileBean}"/>
</p:outputPanel>
</h:form>
If I remove this part (reference to a composite component), the constructor of ViewScopedBean is not called:
<p:outputPanel id="panel">
<ag:profileComponent managedBean="#{viewScopedBean.profileBean}"/>
</p:outputPanel>
All the beans used are set as #ViewScoped.
#ManagedBean
#ViewScoped
public class ViewScopedBean implements Serializable {
private TreeNode selectedNode;
private ProfileBean profileBean;
public ViewScopedBean() {
System.out.println("Constructor of ViewScopedBean " + this);
}
#PostConstruct
public void init() {
System.out.println("ViewScoped init" + this);
profileBean = new ProfileBean();
}
}
Is it the correct behaviour? If not what can cause it?
Update: I tried to use an empty composite, and I have the same problem.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:composite="http://java.sun.com/jsf/composite">
<composite:interface>
<composite:attribute name="managedBean" required="true"/>
</composite:interface>
<composite:implementation>
</composite:implementation>
</html>
But if I made the managedBean not required, that's fine.
Another thing I don't get is when the constructor is called, it seems that the object created is not used.
Initiating the view (console output):
Constructor of ViewScopedBean xxx.bean.ViewScopedBean#4e1d2b8e
2 clicks on the tree:
Constructor of ViewScopedBean xxx.bean.ViewScopedBean#4eb64f2e
Constructor of ViewScopedBean xxx.bean.ViewScopedBean#66863941
Then I open the debug window <ui:debug/>, the viewScopedBean is set to xxx.bean.ViewScopedBean#4e1d2b8e
The view scoped bean will be recreated on every request from/to the same view, when you use JSTL tags like <c:if>, <c:forEach> and so on in the view, or when you bind a JSF component as a property of the view scoped bean using binding attribute. That's apparently what's happening in your composite component.
You need to rewrite your composite component as such that it does not utilize any JSTL tags. Binding some JSF component as a property of the bean can also be avoided in many ways, but if that is really not avoidable, then disabling the partial state saving in web.xml should work in most of the cases:
<context-param>
<param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
<param-value>false</param-value>
</context-param>
If that doesn't work for you, then you really have to share your composite component implementation code with us so that we can point out the caveats and propose the right approaches.
I'm trying out JSF 2.0 (after using ICEfaces 1.8 for the past few months) and I'm trying to figure out why in JSF 2.0 my backing bean constructor gets called multiple times.
The bean is supposed to be instantiated once upon creation, but the "Bean Initialized" text shows up whenever I click the commandButton, indicating a new Bean object being instansiated.
The facelet page:
<?xml version='1.0' encoding='UTF-8' ?>
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html">
<h:body>
<div id="content">
<h:form id="form">
<h:commandButton value="Toggle" action="#{bean.toggleShowMe}"/>
</h:form>
<h:panelGrid rendered="#{bean.showMe}">
<h:outputText value="Show me!"/>
</h:panelGrid>
</div>
</h:body>
</html>
The backing bean:
#ManagedBean
#RequestScoped
public class Bean {
private boolean showMe = false;
public boolean isShowMe() {
return showMe;
}
public void setShowMe(boolean showMe) {
this.showMe = showMe;
}
public void toggleShowMe(){
System.out.println(showMe);
if(showMe==true){
showMe=false;
}else{
showMe=true;
}
}
/** Creates a new instance of Bean */
public Bean() {
System.out.println("Bean Initialized");
}
}
Thats all it is. Just a simple test. The same behaviour shows itself if I use ICEfaces 2.0 and in place of the panelGrid I use:
<ice:panelPopup visible="#{bean.showMe}">
I'd appreciate any help here. I'm at a loss to explain it.
Update: In response to Aba Dov, I #SessionScoped the bean, figuring it wouldn't be calling the constructor upon each request and ran into the same behavior. What am I missing?
You have declared the bean to be placed in the request scope and you're firing a new HTTP request everytime by the command button. Truly the bean will be created on every request.
If you want that the bean lives as long as the view itself (like as IceFaces is doing under the covers for all that ajax stuff), then you need to declare the bean view scoped (this is new in JSF 2.0).
#ManagedBean
#ViewScoped
public class Bean implements Serializable {}
In my case the problem was I imported "javax.faces.bean.ViewScoped" instead of importing "javax.faces.view.ViewScoped".
Hope it could help someone.
The bean is called every time there is a request from the page.
when you click the <h:commandButton> the form is submitted and a request is sent to the server
in order to prevent it you can use <t:saveState> or <a4j:keepAlive> tags for your been.
for example <a4j:keepAlive beanName="YourBean" />
those tags stores the bean instance in the component tree .
also make sure that your class implements Serializable. so it can be serialized
Hope this helps
The bean should be in the ViewScoped.
I am using datatable on page and using binding attribute to bind it to my backing bean. This is my code :-
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:p="http://primefaces.prime.com.tr/ui">
<h:head>
<title>Facelet Title</title>
</h:head>
<h:body>
<h:form prependId="false">
<h:dataTable var="item" value="#{testBean.stringCollection}" binding="#{testBean.dataTable}">
<h:column>
<h:outputText value="#{item}"/>
</h:column>
<h:column>
<h:commandButton value="Click" actionListener="#{testBean.action}"/>
</h:column>
</h:dataTable>
</h:form>
</h:body>
</html>
This is my bean :-
package managedBeans;
import java.io.Serializable;
import java.util.ArrayList;
import java.util.List;
import javax.annotation.PostConstruct;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ViewScoped;
import javax.faces.component.html.HtmlDataTable;
#ManagedBean(name="testBean")
#ViewScoped
public class testBean implements Serializable {
private List<String> stringCollection;
public List<String> getStringCollection() {
return stringCollection;
}
public void setStringCollection(List<String> stringCollection) {
this.stringCollection = stringCollection;
}
private HtmlDataTable dataTable;
public HtmlDataTable getDataTable() {
return dataTable;
}
public void setDataTable(HtmlDataTable dataTable) {
this.dataTable = dataTable;
}
#PostConstruct
public void init(){
System.out.println("Post Construct fired!!");
stringCollection = new ArrayList<String>();
stringCollection.add("a");
stringCollection.add("b");
stringCollection.add("c");
}
public void action(){
System.out.println("Clicked!!");
}
}
Please tell me why is the #PostConstruct firing each and every time i click on button? It should fire only once as long as i am on same page beacause my bean is #ViewScoped. Further, if i remove the binding attribute then everything works fine and #PostConstruct callback fires only once. Then why every time when i use binding attribute? I need binding attribute and want to perform initialisation tasks like fetching data from webservice, etc only once. What should i do? Where should i write my initialisation task?
Interesting, when you're using component binding on a view scoped bean, the view scope breaks.
I am not sure if that is a bug in JSF2, I would have to read the entire JSF2 specification first. As far now your best bet is to drop the component binding for now and pass the selected item via new EL 2.2 method argument syntax:
<h:dataTable var="item" value="#{testBean.stringCollection}">
<h:column>
<h:outputText value="#{item}"/>
</h:column>
<h:column>
<h:commandButton value="Click" action="#{testBean.action(item)}"/>
</h:column>
</h:dataTable>
See also:
How can I pass selected row to commandLink inside dataTable?
Invoke direct methods or methods with arguments / variables / parameters in EL
Benefits and pitfalls of #ViewScoped
Update (Dec 2012): this is indeed a bug in JSF2. It's a chicken-egg issue. The view scoped beans are stored in the JSF view state. So the view scoped beans are only available after restore view phase. However, the binding attribute runs during restore view phase, while the view scoped beans are not available yet. This causes creation of a brand new view scoped bean instance, which is then later replaced by the real view scoped bean which was stored in the restored JSF view state.
This is reported as JSF issue 1492 and JSF spec isssue 787 which will be fixed for JSF 2.2. Until then, your best bet is to use binding on request scoped beans exclusively, or to look for alternate ways for the particular functional requirement.
Update (Mar 2015): The JSF 2.2 fix was backported to Mojarra 2.1.18. So if you're still using JSF 2.0/2.1, you'd best upgrade to at least that version. See also a.o. What is component binding in JSF? When it is preferred to be used? and JSTL in JSF2 Facelets... makes sense?
As other said, I would say that the best thing to do is to drop component binding (you don't need it here).
But I would add that you can achieve the same as you're trying to do in a more object-oriented fashion by using action parameters, like this:
<h:commandButton value="Click" action="#{testBean.action(item)}"/>
... and in your java code:
public void action(Item item){
System.out.println("Clicked!!" + item);
}
If you have a viewscoped bean and if you want to retain values that were entered on the form or don't want postconstruct fired, you should return null from your action method.
If you return some outcome (e.g. invalid) and then point the invalid outcome to the same page using faces-config.xml, then the viewscoped bean gets recreated and thus it causes postconstruct to fire again.
Other solution:
Binding the HtmlDataTable in a request scope bean.
Inject this request scope bean in the view scope bean.
JBoss Seam use this solution for binding JSF componentes to a conversation scope component.
The balusc's answer helped me a lot, i would like to say that i had that bug with mojarra version 2.1.7, i am currently using 2.1.29-01 released in january-2015 and this bug is fixed, my problem was binding a tabview to a viewscoped bean. With this version I dont have that bug and binding and postconstruct is working fine.
I use Jboss 5.2 and i have to use mojarra 2.1.x so i hope this answer help other people in the same situation.
http://mvnrepository.com/artifact/com.sun.faces/jsf-api/2.1.29-01
http://mvnrepository.com/artifact/com.sun.faces/jsf-impl/2.1.29-01