WARN: No se pudo registrar la destrucción de devolución de llamada

15: 11: 14.676 WARN FacesRequestAttributes: 121 - No se pudo registrar la destrucción de devolución de llamada [[email protected]1059fd6] para el atributo 'purchaseController' porque hace FacesRequestAttributes no apoyar este tipo de devoluciones de llamadaWARN: No se pudo registrar la destrucción de devolución de llamada

Este advertir mensaje aparece en mi registro mucho. Por cada frijol administrado cuando caduque. Caduca después de un tiempo dado, porque estoy usando MyFaces Orchestra.

he definido el org.springframework.web.context.request.RequestContextListener en mi web.xml, y yo no tengo el tarro de primavera únicos en mi ruta de clase (es decir, no es un problema de clase de carga)

Los documentos de FacesRequestAttribute dice:

NOTA: A diferencia de ServletRequestAttributes, esta variante no admite devolución de llamadas de destrucción para atributos de ámbito, ni para el alcance de la solicitud ni para el ámbito de la sesión. Si confía en esas devoluciones de llamadas de destrucción implícitas, considere la posibilidad de definir Spring RequestContextListener en su web.xml.

El purchaseController es en realidad un bean gestionado sencillo (que no se extiende nada una implementación única Serializable), anotado con @Controller.

Update1:

Los granos en @Scope("request")@Scope("session") y parece verse afectada. Así que quería saber si esta advertencia representa un peligro para el flujo adecuado. Es decir. si algo realmente necesita esas devoluciones de llamada. Si no, me saltearé la advertencia con la configuración de lo4j.

Actualización 2:

me cavó un poco más lejos, y parece que esto sólo ocurre a veces . SI se utiliza el oyente, entonces RequestContextHolder.currentRequestAttributes() devuelve el ServletRequestAttributes, en lugar de FacesRequestAttributes. Por lo tanto, parece que a veces el oyente no funciona y no establece los atributos actuales en el RequestContextHolder.

Actualización 3:

que resultó en la depuración de RequestContextListener, y aquí está el resultado:

07:21:31,518 DEBUG RequestContextListener:69 - Bound request context to thread: [email protected] 
07:21:31,518 DEBUG RequestContextListener:89 - Cleared thread-bound request context: [email protected] 
07:21:31,538 WARN FacesRequestAttributes:121 - Could not register destruction callback [[email protected]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 [[email protected]1552393] for attribute 'localeController' because FacesRequestAttributes does not support such callbacks 
....and so on, other request and session beans

Parece ser que la solicitud se destruye antes de que el acceso a los granos que se intente. Lo cual es muy extraño. ¿Podría deberse esto a un problema en la implementación del contenedor de servlets del manejo del oyente?

Fuente

2010-01-16 Bozho

¿Cuál es la pregunta/problema? ¿Quieres deshacerte de las advertencias? ¿O desea poder registrar una devolución de llamada de destrucción de alguna manera? – BalusC

Más como si esta devolución de llamada es algo realmente necesario. Porque el marco en sí mismo lo está registrando, no yo. – Bozho

Solo para satisfacer mi curiosidad, ¿qué hay en el método 'destroy()' de estos 'DisposableBeanAdapter' registrados? –

En el javadoc de FacesRequestAttributes, podemos leer:

Nota: En contraste con ServletRequestAttributes, esta variante hace no apoyo devoluciones de llamada de destrucción de los atributos de ámbito, ni para el ámbito de la petición ni para el alcance de la sesión Si confía en esas devoluciones de llamadas de destrucción implícitas, considere definir un Spring RequestContextListener en su web.xml.

Y, de hecho, el método de FacesRequestAttributesregisterDestructionCallback() no hace mucho las cosas:

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

Pero mi opinión es que el RequestContextListener (que ha declarado) se hará cargo de este trabajo. Su método requestDestroyed(ServletRequestEvent requestEvent) se muestra a continuación:

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

Y si nos fijamos en el Javadoc de ServletRequestAttributes#requestCompleted():

Ejecuta todas las devoluciones de llamada de destrucción de petición y actualiza los atributos de la sesión que se ha accedido durante el procesamiento de la solicitud.

Por lo tanto, creo que se puede omitir la configuración de WARN con log4j (tal vez confirmar esto con una pequeña sesión de depuración).

Fuente

2010-01-16 21:26:35

Gracias, +1 por el tiempo invertido. He profundizado un poco más, y parece que esto solo ocurre a veces. Como usted (y yo) citamos, FacesRequestAttributes no tiene devolución de llamada. Pero si se usa el oyente, entonces RequestContextHolder.currentRequestAttributes(); devuelve ServletRequestAttributes, en lugar de FacesRequestAttributes. Por lo tanto, parece que a veces el oyente no funciona ... – Bozho

Extraño, el método que menciona debe * Volver al actual JSF FacesContext, si hay alguno *. Pero estoy hablando un poco de mi trasero y me siento demasiado perezosa esta noche para ir más allá :) –

sí, vuelve a FacesContext mediante la construcción de un nuevo FacesContextAttributes (FacesContext.getCurrentInstance()), y ese es el problema - este objeto no registra devoluciones de llamada. ¿Cuál puede ser la razón para que recurra a él en lugar de usar el registrado por el oyente? – Bozho

He intentado añadir

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

según lo sugerido por erhan14 en este forum post.

Y esa advertencia desapareció para mí. Espero eso ayude.

Fuente

2012-12-30 02:46:23 Boon

El OP ya lo hizo. Lea el segundo párrafo de la pregunta. – BalusC

Gracias por notar mi error. – Boon

WARN: No se pudo registrar la destrucción de devolución de llamada

Respuesta

Cuestiones relacionadas