ПРЕДУПРЕДИТЕ: не Мог зарегистрировать обратный вызов разрушения

Question

ПРЕДУПРЕДИТЕ: не Мог зарегистрировать обратный вызов разрушения

15:11:14 676 ПРЕДУПРЕЖДАЕТ, что FacesRequestAttributes:121 - не Мог зарегистрировать обратный вызов разрушения [org.springframework.beans.factory.support.DisposableBeanAdapter@1059fd6] для атрибута 'purchaseController', потому что FacesRequestAttributes не поддерживает такие обратные вызовы

Это предупреждает, что сообщение появляется в моем журнале много. Для каждого управляемого компонента каждый раз, когда это истекает. Это истекает после данного времени, потому что я использую Оркестр MyFaces.

Я определил org.springframework.web.context.request.RequestContextListener в моем web.xml, и у меня нет пружинной банки только на моем пути к классу (т.е. не загружающая класс проблема)

В документах FacesRequestAttribute говорится:

Примечание: В отличие от ServletRequestAttributes, этот вариант не поддерживает обратные вызовы разрушения для ограниченных по объему атрибутов, ни для объема запроса, ни для объема сессии. Если Вы полагаетесь на такие неявные обратные вызовы разрушения, рассматриваете определение Spring RequestContextListener в Вашем web.xml.

purchaseController на самом деле простой управляемый компонент (не расширяющий ничто реализация только Serializable), аннотируемый @Controller.

Update1:

Бобы в @Scope("request") и @Scope("session") кажется, затронут. Таким образом, я хотел знать, предупреждает ли это, создает любую опасность для надлежащего потока. Т.е. если чему-то действительно нужны те обратные вызовы. В противном случае я просто пропущу предупреждение с конфигурацией lo4j.

Обновление 2:

Я вырыл немного далее, и кажется, что это происходит только иногда. ЕСЛИ слушатель используется, то RequestContextHolder.currentRequestAttributes() возвраты ServletRequestAttributes, вместо FacesRequestAttributes. Таким образом, кажется, что иногда слушатель не работает и не устанавливает текущие атрибуты в RequestContextHolder.

Обновление 3:

Я включил отладку для RequestContextListener, и вот результат:

07:21:31,518 DEBUG RequestContextListener:69 - Bound request context to thread: org.apache.catalina.connector.RequestFacade@1190ae9
07:21:31,518 DEBUG RequestContextListener:89 - Cleared thread-bound request context: org.apache.catalina.connector.RequestFacade@1190ae9
07:21:31,538  WARN FacesRequestAttributes:121 - Could not register destruction callback [org.springframework.beans.factory.support.DisposableBeanAdapter@11aa152] for attribute 'org.apache.myfaces.orchestra.conversation.AccessScopeManager' because FacesRequestAttributes does not support such callbacks
07:21:31,541  WARN FacesRequestAttributes:121 - Could not register destruction callback [org.springframework.beans.factory.support.DisposableBeanAdapter@1552393] for attribute 'localeController' because FacesRequestAttributes does not support such callbacks
....and so on, other request and session beans

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

11

java spring jsf orchestra

задан Bozho 17 January 2010 в 08:53

1 ответ

Другие вопросы по тегам:

java spring jsf orchestra

Похожие вопросы:

score 11 · Accepted Answer

В Javadoc FacesRequestattributes , мы можем прочитать:

Примечание: В отличие от СервелетейкВестеТтрибусы , этот вариант не Поддержка обратных вызовов разрушений для атрибутов Scoped, ни для охвата запроса, ни для области сеанса. Если вы полагаетесь на такие неявные обратные вызовы разрушений, рассмотрите возможность определения пружины requestlexLextListener в вашем web.xml.

И, действительно, метод RegisterDestructionCallback () метод FaceSrequestattributes не делает много вещей:

public void registerDestructionCallback(String name, Runnable callback, int scope) {
    if (logger.isWarnEnabled()) {
        logger.warn("Could not register destruction callback [" + callback + "] for attribute '" + name +
                        "' because FacesRequestAttributes does not support such callbacks");
    }
}

, но мое понимание состоит в том, что requestextLextListener что вы заявили) позаботится об этой работе. Это RequestedEsseStreyed (Servletrequestevent WhiteeEvent) метод показан ниже:

public void requestDestroyed(ServletRequestEvent requestEvent) {
   ServletRequestAttributes attributes =
           (ServletRequestAttributes) requestEvent.getServletRequest().getAttribute(REQUEST_ATTRIBUTES_ATTRIBUTE);
   ServletRequestAttributes threadAttributes =
           (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
   if (threadAttributes != null) {
       // We're assumably within the original request thread...
       if (attributes == null) {
           attributes = threadAttributes;
       }
       RequestContextHolder.resetRequestAttributes();
       LocaleContextHolder.resetLocaleContext();
   }
   if (attributes != null) {
       attributes.requestCompleted();
       if (logger.isDebugEnabled()) {
           logger.debug("Cleared thread-bound request context: " + requestEvent.getServletRequest());
       }
   }
}

и если вы посмотрите на Javadoc Servletrequestattribute # RequestCompleted () :

Выполняет все обратные вызовы разрушений запроса. Атрибуты сеанса, доступные во время обработки запроса.

Итак, я думаю, что вы можете безопасно пропустить предупреждение с конфигурацией Log4j (возможно, подтвердите это с небольшим сеансом отладки).