ВНИМАНИЕ: Не удалось зарегистрировать обратный вызов уничтожения

Question

15: 11: 14,676 WARN FacesRequestAttributes: 121 - Не удалось зарегистрировать обратный вызов уничтожения [org.springframework.beans.factory.support.DisposableBeanAdapter@1059fd6] для атрибута purchaseController, поскольку FacesRequestAttributes не поддерживает такие обратные вызовы

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

Я определил 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

Похоже, что запрос уничтожается до попытки доступа к bean-компонентам. Что очень странно. Может ли это быть связано с проблемой в реализации контейнера слушателя обработки слушателя?

Answer 1

В javadoc FacesRequestAttributes мы можем читать:

Примечание: В отличие от ServletRequestAttributesэтот вариант не поддерживает обратные вызовы уничтожения для атрибутов области действия ни для области запроса, ни для области сеанса.Если вы полагаетесь на такие неявные обратные вызовы уничтожения, рассмотрите возможность определения Spring RequestContextListener в вашем файле 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");
    }
}

Но я понимаю, чтоRequestContextListener (что вы заявили) позаботится об этой работе.Его requestDestroyed(ServletRequestEvent requestEvent) метод показан ниже:

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 ServletRequestAttributes#requestCompleted():

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

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

Answer 2

Я попытался добавить

<listener>
    <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>

, как предложено erhan14 в этом сообщении на форуме .

И это предупреждение исчезло для меня.Надеюсь, это поможет.