Почему JSF вызывает геттеры несколько раз

С помощью JSF 2.0 вы можете подключить прослушиватель к системному событию

<h:outputText value="#{ManagedBean.someProperty}">
   <f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />
</h:outputText>

В качестве альтернативы вы можете заключить страницу JSF в f:view tag

<f:view>
   <f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />

      .. jsf page here...

<f:view>

Я написал статьи о том, как кэшировать JSF beans getter с Spring AOP.

Я создаю простой MethodInterceptor который перехватывает все методы, аннотированные специальной аннотацией:

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;
}

}

этот перехватчик используется в файле конфигурации spring:

    <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>

надеюсь, что это поможет!

Первоначально опубликовано в PrimeFaces forum @ http://forum.primefaces.org/viewtopic.php?f=3&t=29546

недавно я был одержим оценкой производительности моего приложения, настройкой запросов JPA, заменой динамических SQL-запросов именованными запросами, и только сегодня утром я понял, что метод getter был более горячей точкой в Java Visual VM, чем остальная часть моего кода (или большинство моего кода).

Getter метод:

PageNavigationController.getGmapsAutoComplete()

ссылка ui: включить в индекс.xhtml

ниже, вы увидите, что PageNavigationController.getGmapsAutoComplete () является горячей точкой (проблема производительности) в Java Visual VM. Если вы посмотрите дальше вниз, на захват экрана, вы увидите, что getLazyModel (), PrimeFaces lazy datatable getter метод, является горячей точкой тоже, только когда конечный пользователь делает много "ленивый datatable" типа материала/операций/задач в приложении. :)

Посмотреть (оригинал) код под.

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;
}

ссылается на следующее в индексе.xhtml:

<h:head>
    <ui:include src="#{pageNavigationController.gmapsAutoComplete ? '/head_gmapsAutoComplete.xhtml' : (pageNavigationController.gmaps ? '/head_gmaps.xhtml' : '/head_default.xhtml')}"/>
</h:head>

решение: поскольку это метод "getter", переместите код и назначьте значение gmapsAutoComplete до вызова метода; см. код ниже.

/*
 * 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;
    }
}

результаты теста: PageNavigationController.getGmapsAutoComplete() больше не является горячей точкой в Java Visual VM (даже не появляется больше)

общий доступ к этой теме, так как многие из опытных пользователей посоветовали junior JSF разработчики не добавляют код в методы "getter". :)

вероятно, вы можете использовать AOP для создания какого-то аспекта, который кэширует результаты наших геттеров в течение настраиваемого периода времени. Это избавит вас от необходимости копировать и вставлять шаблонный код в десятки методов доступа.

Если вы используете CDI, вы можете использовать методы производителей. Он будет вызываться много раз, но результат первого вызова кэшируется в области Боба и эффективен для геттеров, которые вычисляют или инициализируют тяжелые объекты! Смотрите здесь, для получения дополнительной информации.

Это все еще большая проблема в JSF. Например, если у вас есть метод isPermittedToBlaBla для проверки безопасности, и на ваш взгляд у вас есть rendered="#{bean.isPermittedToBlaBla} тогда метод будет вызываться несколько раз.

проверка безопасности может быть сложной, например . LDAP-запрос и т. д. Поэтому вы должны избегать этого с

Boolean isAllowed = null ... if(isAllowed==null){...} return isAllowed?

и вы должны обеспечить в сеансовом компоненте это за запрос.

Ich думаю, что JSF должен реализовать здесь некоторые расширения, чтобы избежать нескольких вызовов (например, аннотации @Phase(RENDER_RESPONSE) calle этот метод только один раз после RENDER_RESPONSE этап...)

Если значение someProperty равно дорого рассчитать, это может потенциально это проблема.

Это то, что мы называем преждевременная оптимизация. В редких случаях, когда профилировщик сообщает вам, что вычисление свойства настолько чрезвычайно дорого, что вызов его три раза, а не один раз оказывает значительное влияние на производительность, вы добавляете кэширование, как вы описываете. Но если вы не сделаете что-то действительно глупое, как факторинг простыми или доступа к база данных в геттере, ваш код, скорее всего, имеет дюжину худших неэффективностей в местах, о которых вы никогда не думали.