WARNUNG: Konnten Sie nicht registrieren, Vernichtung, Rückruf

15:11:14,676 WARNEN FacesRequestAttributes:121 - Konnten Sie nicht registrieren, Zerstörung callback - [org.springframework.beans.factory.support.DisposableBeanAdapter@1059fd6] für das Attribut 'purchaseController", weil FacesRequestAttributes unterstützt nicht solche Rückrufe

Diese warn-Meldung erscheint in meinem log viel. Für jede managed-bean, sobald er abgelaufen ist. Es läuft nach einer bestimmten Zeit, denn ich bin mit MyFaces Orchestra.

Ich habe die org.springframework.web.context.request.RequestContextListener in meinem web.xml, und ich habe nicht die Feder jar einzigen, die auf mein classpath (also nicht class-loading-problem)

Den docs von FacesRequestAttribute sagt:

HINWEIS: Im Gegensatz zu ServletRequestAttributes, wird diese Variante nicht unterstützt, Zerstörung Rückrufe für scoped Attribute, weder für die Anfrage Umfang noch für den Gültigkeitsbereich einer session. Wenn du dich auf solche implizite Zerstörung Rückrufe, betrachten Sie definieren eine Feder in Ihrem RequestContextListener web.xml.

Den purchaseController ist eigentlich ein einfacher managed bean (nicht länger alles, was eine Umsetzung nur Serializable), versehen mit @Controller.

Update1:

Werden die Bohnen in @Scope("request") und @Scope("session") scheinen betroffen zu sein.
Also wollte ich wissen, ob diese warnen, stellt keine Gefahr für die richtige Strömung. I. e. wenn etwas wirklich braucht diese Rückrufe. Wenn nicht, werde ich einfach überspringen Sie die Warnung mit der lo4j config.

Update 2:

Ich grub ein wenig weiter, und es scheint, dass dies geschieht nur manchmal. WENN der Hörer verwendet wird, dann RequestContextHolder.currentRequestAttributes() gibt die ServletRequestAttributes eher als FacesRequestAttributes. So es scheint, dass manchmal der Hörer nicht funktioniert und nicht die aktuellen Attribute in der RequestContextHolder.

Update 3:

Drehte ich debug auf für RequestContextListener, und hier ist das Ergebnis:

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

Scheint es, dass die Anforderung zerstört wird, bevor der Zugang zu den Bohnen versucht. Das ist sehr seltsam. Dies könnte sein, dass aufgrund eines Problems in der servlet-container-Implementierung der listener-handling?

Was ist die Frage/problem? Sie wollen, um loszuwerden, die Warnungen? Oder Sie wollen in der Lage sein, zu registrieren, eine Vernichtung, Rückruf in irgendeiner Weise?
Mehr, wie, ob dieser Rückruf ist etwas, was wirklich gebraucht wird. Da das framework selbst ist, registrieren Sie ihn, nicht mich.
Nur um meine Neugierde zu befriedigen, was gibt es in der destroy() Methode dieser registriert DisposableBeanAdapter?
In meiner Bohnen (Controller) gibt es nichts. Also momentan ist es kein problem, dass dies nicht gelingt. Aber wenn ich auf add a custom destroy () - Methode (ohne Implementierung DisposableBean), dann fürchte ich, es wird nicht aufgerufen werden, in diesen Situationen. (Die DisposableBeanAdapter findet, und ruft die benutzerdefinierte zerstören, Methoden)

InformationsquelleAutor Bozho | 2010-01-16

10

In der javadoc von FacesRequestAttributes, können wir Lesen:

Hinweis: Im Gegensatz zu ServletRequestAttributes, diese Variante gilt nicht unterstützen Zerstörung Rückrufe für scoped Attribute, weder für die Anfrage Umfang noch für den Gültigkeitsbereich einer session. Wenn du dich auf solche implizite Zerstörung Rückrufe, betrachten die Definition einer Feder RequestContextListener in Ihrem web.xml.

Und, in der Tat, die registerDestructionCallback() Methode der FacesRequestAttributes nicht viel Dinge:
```
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");
    }
}
```
Aber mein Verständnis ist, dass die RequestContextListener (dass die Sie deklariert haben) übernehmen diese Aufgabe. Seine requestDestroyed(ServletRequestEvent requestEvent) Methode ist unten dargestellt:
```
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());
       }
   }
}
```
Und wenn Sie sich die javadoc von ServletRequestAttributes#requestCompleted():

Führt alle Anfrage Zerstörung Rückrufe und updates der session-Attribute, auf die zugegriffen wurde, bei der Verarbeitung von Anfragen.

So, ich denke das kann man getrost überspringen, WARNEN mit log4j-Konfiguration (vielleicht bestätigen Sie diese mit ein wenig debugging-Sitzung).

Danke, +1 für die aufgewendete Zeit. Ich grub ein wenig weiter, und es scheint, dass dies geschieht nur manchmal. Wie Sie (und mich) zitiert, FacesRequestAttributes nicht über Rückrufe. Aber WENN der Hörer verwendet wird, dann RequestContextHolder.currentRequestAttributes(); liefert die ServletRequestAttributes, anstatt FacesRequestAttributes. So es scheint, dass manchmal der Hörer funktioniert nicht..
Komisch, die Methode, die Sie erwähnen sollten, zurückgreifen, um die aktuelle JSF-FacesContext, wenn überhaupt. Aber ich bin irgendwie spricht aus meinem Arsch und das Gefühl zu faul, heute Abend weiter zu gehen 🙂
ja, es fällt zurück auf den FacesContext über den Bau einer neuen FacesContextAttributes(FacesContext.getCurrentInstance()), und das ist das problem - dieses Objekt nicht registrieren callbacks. Was kann der Grund sein, für Sie fallen zurück, um es, statt mit dem one registriert den listener.

InformationsquelleAutor Pascal Thivent
4

Habe ich versucht, indem
```
<listener>
    <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
</listener>
```
vorgeschlagen von erhan14 auf dieser forum-post.

Und die Warnung verschwand für mich. Hoffe, es hilft.

Die OP schon gemacht. Lesen Sie den 2. Absatz der Frage.
Vielen Dank für bemerken, mein Fehler.

InformationsquelleAutor Boon

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.