Let's say I specify an outputText component like this:
<h:outputText value="#{ManagedBean.someProperty}"/>
If I print a log message when the getter for someProperty is called and load the page, it is trivial to notice that the getter is being called more than once per request (twice or three times is what happened in my case):
DEBUG 2010-01-18 23:31:40,104 (ManagedBean.java:13) - Getting some property
DEBUG 2010-01-18 23:31:40,104 (ManagedBean.java:13) - Getting some property
If the value of someProperty is expensive to calculate, this can potentially be a problem.
I googled a bit and figured this is a known issue. One workaround was to include a check and see if it had already been calculated:
private String someProperty;
public String getSomeProperty() {
if (this.someProperty == null) {
this.someProperty = this.calculatePropertyValue();
}
return this.someProperty;
}
The main problem with this is that you get loads of boilerplate code, not to mention private variables that you might not need.
What are the alternatives to this approach? Is there a way to achieve this without so much unnecessary code? Is there a way to stop JSF from behaving in this way?
Thanks for your input!
This is caused by the nature of deferred expressions #{} (note that "legacy" standard expressions ${} behave exactly the same when Facelets is used instead of JSP). The deferred expression is not immediately evaluated, but created as a ValueExpression object and the getter method behind the expression is executed everytime when the code calls ValueExpression#getValue().
This will normally be invoked one or two times per JSF request-response cycle, depending on whether the component is an input or output component (learn it here). However, this count can get up (much) higher when used in iterating JSF components (such as <h:dataTable> and <ui:repeat>), or here and there in a boolean expression like the rendered attribute. JSF (specifically, EL) won't cache the evaluated result of the EL expression at all as it may return different values on each call (for example, when it's dependent on the currently iterated datatable row).
Evaluating an EL expression and invoking a getter method is a very cheap operation, so you should generally not worry about this at all. However, the story changes when you're performing expensive DB/business logic in the getter method for some reason. This would be re-executed everytime!
Getter methods in JSF backing beans should be designed that way that they solely return the already-prepared property and nothing more, exactly as per the Javabeans specification. They should not do any expensive DB/business logic at all. For that the bean's #PostConstruct and/or (action)listener methods should be used. They are executed only once at some point of request-based JSF lifecycle and that's exactly what you want.
Here is a summary of all different right ways to preset/load a property.
public class Bean {
private SomeObject someProperty;
#PostConstruct
public void init() {
// In #PostConstruct (will be invoked immediately after construction and dependency/property injection).
someProperty = loadSomeProperty();
}
public void onload() {
// Or in GET action method (e.g. <f:viewAction action>).
someProperty = loadSomeProperty();
}
public void preRender(ComponentSystemEvent event) {
// Or in some SystemEvent method (e.g. <f:event type="preRenderView">).
someProperty = loadSomeProperty();
}
public void change(ValueChangeEvent event) {
// Or in some FacesEvent method (e.g. <h:inputXxx valueChangeListener>).
someProperty = loadSomeProperty();
}
public void ajaxListener(AjaxBehaviorEvent event) {
// Or in some BehaviorEvent method (e.g. <f:ajax listener>).
someProperty = loadSomeProperty();
}
public void actionListener(ActionEvent event) {
// Or in some ActionEvent method (e.g. <h:commandXxx actionListener>).
someProperty = loadSomeProperty();
}
public String submit() {
// Or in POST action method (e.g. <h:commandXxx action>).
someProperty = loadSomeProperty();
return "outcome";
}
public SomeObject getSomeProperty() {
// Just keep getter untouched. It isn't intented to do business logic!
return someProperty;
}
}
Note that you should not use bean's constructor or initialization block for the job because it may be invoked multiple times if you're using a bean management framework which uses proxies, such as CDI.
If there are for you really no other ways, due to some restrictive design requirements, then you should introduce lazy loading inside the getter method. I.e. if the property is null, then load and assign it to the property, else return it.
public SomeObject getSomeProperty() {
// If there are really no other ways, introduce lazy loading.
if (someProperty == null) {
someProperty = loadSomeProperty();
}
return someProperty;
}
This way the expensive DB/business logic won't unnecessarily be executed on every single getter call.
See also:
Why is the getter called so many times by the rendered attribute?
Invoke JSF managed bean action on page load
How and when should I load the model from database for h:dataTable
How to populate options of h:selectOneMenu from database?
Display dynamic image from database with p:graphicImage and StreamedContent
Defining and reusing an EL variable in JSF page
Measure the render time of a JSF view after a server request
With JSF 2.0 you can attach a listener to a system event
<h:outputText value="#{ManagedBean.someProperty}">
<f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />
</h:outputText>
Alternatively you can enclose the JSF page in an f:view tag
<f:view>
<f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />
.. jsf page here...
<f:view>
I have written an article about how to cache JSF beans getter with Spring AOP.
I create a simple MethodInterceptor which intercepts all methods annotated with a special annotation:
public class CacheAdvice implements MethodInterceptor {
private static Logger logger = LoggerFactory.getLogger(CacheAdvice.class);
#Autowired
private CacheService cacheService;
#Override
public Object invoke(MethodInvocation methodInvocation) throws Throwable {
String key = methodInvocation.getThis() + methodInvocation.getMethod().getName();
String thread = Thread.currentThread().getName();
Object cachedValue = cacheService.getData(thread , key);
if (cachedValue == null){
cachedValue = methodInvocation.proceed();
cacheService.cacheData(thread , key , cachedValue);
logger.debug("Cache miss " + thread + " " + key);
}
else{
logger.debug("Cached hit " + thread + " " + key);
}
return cachedValue;
}
public CacheService getCacheService() {
return cacheService;
}
public void setCacheService(CacheService cacheService) {
this.cacheService = cacheService;
}
}
This interceptor is used in a spring configuration file:
<bean id="advisor" class="org.springframework.aop.support.DefaultPointcutAdvisor">
<property name="pointcut">
<bean class="org.springframework.aop.support.annotation.AnnotationMatchingPointcut">
<constructor-arg index="0" name="classAnnotationType" type="java.lang.Class">
<null/>
</constructor-arg>
<constructor-arg index="1" value="com._4dconcept.docAdvance.jsfCache.annotation.Cacheable" name="methodAnnotationType" type="java.lang.Class"/>
</bean>
</property>
<property name="advice">
<bean class="com._4dconcept.docAdvance.jsfCache.CacheAdvice"/>
</property>
</bean>
Hope it will help!
Originally posted in PrimeFaces forum # http://forum.primefaces.org/viewtopic.php?f=3&t=29546
Recently, I have been obsessed evaluating the performance of my app, tuning JPA queries, replacing dynamic SQL queries with named queries, and just this morning, I recognized that a getter method was more of a HOT SPOT in Java Visual VM than the rest of my code (or majority of my code).
Getter method:
PageNavigationController.getGmapsAutoComplete()
Referenced by ui:include in in index.xhtml
Below, you will see that PageNavigationController.getGmapsAutoComplete() is a HOT SPOT (performance issue) in Java Visual VM. If you look further down, on the screen capture, you will see that getLazyModel(), PrimeFaces lazy datatable getter method, is a hot spot too, only when enduser is doing a lot of 'lazy datatable' type of stuff/operations/tasks in the app. :)
See (original) code below.
public Boolean getGmapsAutoComplete() {
switch (page) {
case "/orders/pf_Add.xhtml":
case "/orders/pf_Edit.xhtml":
case "/orders/pf_EditDriverVehicles.xhtml":
gmapsAutoComplete = true;
break;
default:
gmapsAutoComplete = false;
break;
}
return gmapsAutoComplete;
}
Referenced by the following in index.xhtml:
<h:head>
<ui:include src="#{pageNavigationController.gmapsAutoComplete ? '/head_gmapsAutoComplete.xhtml' : (pageNavigationController.gmaps ? '/head_gmaps.xhtml' : '/head_default.xhtml')}"/>
</h:head>
Solution: since this is a 'getter' method, move code and assign value to gmapsAutoComplete prior to method being called; see code below.
/*
* 2013-04-06 moved switch {...} to updateGmapsAutoComplete()
* because performance = 115ms (hot spot) while
* navigating through web app
*/
public Boolean getGmapsAutoComplete() {
return gmapsAutoComplete;
}
/*
* ALWAYS call this method after "page = ..."
*/
private void updateGmapsAutoComplete() {
switch (page) {
case "/orders/pf_Add.xhtml":
case "/orders/pf_Edit.xhtml":
case "/orders/pf_EditDriverVehicles.xhtml":
gmapsAutoComplete = true;
break;
default:
gmapsAutoComplete = false;
break;
}
}
Test results: PageNavigationController.getGmapsAutoComplete() is no longer a HOT SPOT in Java Visual VM (doesn't even show up anymore)
Sharing this topic, since many of the expert users have advised junior JSF developers to NOT add code in 'getter' methods. :)
If you are using CDI, you can use Producers methods.
It will be called many times, but the result of first call is cached in scope of the bean and is efficient for getters that are computing or initializing heavy objects!
See here, for more info.
You could probably use AOP to create some sort of Aspect that cached the results of our getters for a configurable amount of time. This would prevent you from needing to copy-and-paste boilerplate code in dozens of accessors.
If the value of someProperty is
expensive to calculate, this can
potentially be a problem.
This is what we call a premature optimization. In the rare case that a profiler tells you that the calculation of a property is so extraordinarily expensive that calling it three times rather than once has a significant performance impact, you add caching as you describe. But unless you do something really stupid like factoring primes or accessing a databse in a getter, your code most likely has a dozen worse inefficiencies in places you've never thought about.
I would also advice using such Framework as Primefaces instead of stock JSF, they address such issues before JSF team e. g in primefaces you can set partial submit. Otherwise BalusC has explained it well.
It still big problem in JSF. Fo example if you have a method isPermittedToBlaBla for security checks and in your view you have rendered="#{bean.isPermittedToBlaBla} then the method will be called multiple times.
The security check could be complicated e.g . LDAP query etc. So you must avoid that with
Boolean isAllowed = null ... if(isAllowed==null){...} return isAllowed?
and you must ensure within a session bean this per request.
Ich think JSF must implement here some extensions to avoid multiple calls (e.g annotation #Phase(RENDER_RESPONSE) calle this method only once after RENDER_RESPONSE phase...)
i have next method:
public int countEvents(List<EventTypeEnum> eventTypes)
now how to call this method from unified EL ?
With non collection enum arguments works fine but not with collection
Tried
${countEvents("ALERT")}
${countEvents(["ALERT"])}
both crashes
If the values are fixed, you might just do this:
public int countEvents(List<EventTypeEnum> eventTypes) { ... }
public int countAlerts() {
return countEvents(Arrays.asList(EventTypeEnum.ALERT));
}
${countAlerts()}
This is usually the simplest and clearest solution.
Enums could be treated as strings in jstl. But there is no direct way by which you could create a list in jstl. You need to have a list of evenTypes in scope, say ${eventTypes}, which is a List<EventTypeEnum> then you could directly the method in you bean like ${bean.countEvents(eventTypes)}.
However from your code i presume you need to create this on the fly. In that case you'll have to rely on standard jsp. Say you have an enum
public enum EventTypeEnum {
ALERT, ONCLICK, ONBLUR
}
And a pojo which has the count method like
import java.util.List;
public class CountBean {
public int countEvents(List<EventTypeEnum> eventTypes){
return eventTypes.size();
}
}
So if you have an instance of CountBean in scope, say ${myBean} then in you jsp you could do like
<jsp:useBean id="events" class="java.util.ArrayList">
<%
events.add("ALERT");
events.add("ONCLICK");
%>
</jsp:useBean>
Length : <c:out value="${myBean.countEvents(events)}"/>
This would work fine. If you dont want to use <jsp:useBean> approach you could use MicroNova YUZU tags. It is an open-source EL-based JSP tag libary designed to augment JSTL. More details could be found on http://www.micronova.com/yuzu.jsp.
If you dont want to create bean instances to invoke this method and wish to use it as static you could create custom jstl methods as explained here or here.
Hope this helps.
Right now I use the f:viewParam tag to inject the request parameter into a field of my bean
<f:viewParam name="id" value="#{surveyController.id}" />
But I would much rather prefer to use annotations for this. I know about the #Value annotation, and I guess I could do something like this
#Component
#Scope("view")
public class SurveyControlador {
#Value("#{new Long.parseLong('${param.id}')}")
private Long id;
....
}
But this is just plain ugly.
Is there a better way, where I don't need to convert the value explicitly, and maybe even omit the "param"? I'm even willing to install third party libraries
I've used omnifaces' #Param successfully, like so:
#Named #ViewScoped
public class SurveyController {
#Inject #Param(name = "id")
private ParamValue<Long> idParam;
public void doStuff() {
if (idParam.getValue().equals(1)) {
throw new IllegalAccessException("you don't dare");
}
}
}
Pro: You additionally get access to the raw submitted value and omnifaces optionally applies validations/conversions (check the docs).
Con: Wrapper around your real parameter. And you still need to specify <f:viewParam> (you don't need to bind it to a backing bean, tho) if you want to keep the parameter for navigation.
Note that this leverages CDI, which may or may not fit the way you do things.
I would like to write my business logic after the getters and setters are called (twice),
because I use their object values inside the business logic.
However Construct, Post construct, actionevents,.. are called before the getters.
So how can I use the values of the getters if I don't want to write business logic inside them?
I want to navigate to the site and get data from a database displayed into outputText.
Do the job in (post)constructor of the bean.
#ManagedBean
#RequestScoped
public class Bean {
private String data;
#EJB
private SomeService service;
#PostConstruct
public void init() {
data = service.load();
}
// Getter.
}
with
<h:outputText value="#{bean.data}" />
When I change a (primefaces)selectOneMenu value the bean gets the selectOneMenu's value and performs a query in the database for this value, and writes the query result inside the outputText.
Do the job in the ajax listener method of the bean which is attached to input component's change event.
#ManagedBean
#ViewScoped
public class Bean {
private String selectedItem;
private String result;
#EJB
private SomeService service;
public void changeSelectedItem(AjaxBehaviorEvent event) {
result = service.find(selectedItem);
}
// Getters+setter.
}
with
<p:selectOneMenu value="#{bean.selectedItem}">
<f:selectItems ... />
<p:ajax listener="#{bean.changeSelectedItem}" update="result" />
</p:selectOneMenu>
<h:outputText id="result" value="#{bean.result}" />
Doing it after the getters are called would be too late. JSF would at that point already be finished with rendering the HTML output. You can't change the HTML output afterwards.
You are making a basic mistake in your thinking.
There is no such phase as "The Getters". Getters are just a convention to read a property of a bean.
Those properties can be read individually throughout the entire request. Some may be consulted as early as during "create/restore view", while others may be consulted during "render response".
There is no such thing as that JSF in one particular phase does a sweep through your code and for the fun of it calls every getter it finds.
The solution for you is to let this thinking go. I know it might be hard to let go of something you think is true, but inhale, clear you mind, say goodbye to your current understanding of how things work, and just re-learn from scratch.
You'll then find the answer yourself in no-time. Good luck!
Did not understand your question fully, but obvious way is to put logic in getters and setters.
I have simple scenario, this example comes from PrimeFaces, but I guess it applies for every tag I would use in a similar way:
<p:autoComplete value="#{address.country}" id="#{layoutId}_country"
completeMethod="#{addressBean.completeCountry}" var="country"
itemLabel="#{country.name}" itemValue="#{country}"
converter="#{countryConverter}">
</p:autoComplete>
In a method of a bean (eg. addressBean.completeCounty) I have access to an AutoComplete object. What I'd like to get is the reference of its value (#{address.country}), not the value itself.
Where is that bound to?
What I'd like to get is the reference of its value (#{address.country}), not the value itself.
This question is a bit vague (it's likely the language barrier), but if I understand you correctly, you'd like to get #{address.country} as expression string for some reason. You can get it by UIComponent#getValueExpression() and then ValueExpression#getExpressionString().
public List<Country> completeCountry(String query) {
UIComponent component = UIComponent.getCurrentComponent(FacesContext.getCurrentInstance());
String valueEL = component.getValueExpression("value").getExpressionString();
// ...
}