ManagedBean resolved to null

Java-Forum Jakarta EE (Java EE)
1

Hi!

Ich habe in einer ManagedBean etwa 400 Zeilen Code mit etwa 60 Methoden. Im PostConstruct wird eine Liste aus einem BO in eine Property bzw. Member geholt. In einigen von den 60 Methoden werden aus dieser Liste einzelne Werte oder Summen, per .stream().filter()… geholt. Alles kompakte Einzeiler. Das klappt wunderbar.

Sobald ich nur eine Methode zu viel habe, dann streikt das System und gibt diesen Log aus

./catalina.2016-08-25.log:25-Aug-2016 15:20:44.272 
WARNING [http-apr-8080-exec-281] null.null #{listBean.submitAction()}: 
javax.el.PropertyNotFoundException: /dieseite.xhtml @111,111 
action="#{listBean.submitAction()}": 
Target Unreachable, identifier 'listBean' resolved to null

Woran liegt das?
Was kann man dagegen tun?
Wonach kann ich suchen?

Danke schon mal :slight_smile:

2

Das verstehe ich (vom Inhalt her) nicht. Mit 60 Methoden funktioniert es, mit 61 nicht mehr?

3

Ja, das klingt komisch. Aber dieses Problem mit 400 Zeilen code und 60 Methoden kenn ich persönlich auch schon sehr lange nicht mehr.

4

Ja! Es ist eine wirklich komische Sache.

Es reicht sogar, wenn ich in eine Methode nur eine zusätzliche Zeile dazuschreibe. Dann hört das ganze auf zu funktionieren. Ich bekomme keine Fehlermeldung ausser dem o.g. Log.

Naja, irgendwo muß ich die Einzelwerte aus der Liste rausfrickeln.

5

Hast du einen Unit Test für die Backing Bean und ihre Methoden? Ist er positiv oder verhält er sich ähnlich? Hast du in die Backing Bean schon herein gedebuggt, wird der Konstruktor aufgerufen?

Um dir zu helfen brauchen wir leider mehr Informationen. Welche JSF Version, welcher AppServer? Ist es möglich, Code zu posten der den Fehler provoziert?

6

UnitTests habe ich keine gemacht. Der Code ist mit BreakPoints übersäht und Konstruktor wurde nicht aufgerufen.

Sobald eine Zeile Code zuviel in der ManagedBean steht oder der Code zu kompliziert wird, dann läuft es nicht mehr. Aus u.g. Code muß ich eine der Zeilen rauskommentieren, damit es funktioniert. Egal aus welcher Methode, aber hauptsache eine Zeile ist weg. Mittlerweile habe ich das gleiche Problem mit anderem Code, der eigentlich auch nichts besonderes macht.

Code z.B.:

public double getErgebnis(List<ListModel> list){
        double summe1 = list().filter(w -> w.getAbc().equals("A")).mapToDouble(w -> w.getWert1()).sum();
        double summe2 = list().filter(w -> w.getAbc().equals("B")).mapToDouble(w -> w.getWert2()).sum();
        
        //return (summe1 - summe2);

	return 0;
    }

Software: JSF 2.2, Tomcat 8.0.20, JDK1.8.0_66

Es ist ja nicht so, dass ich mir nicht hätte helfen können. Ich habe den Code in die BOs gepackt, obwohl diese Kleinigkeiten eine Angelegenheit der Darstellung sind und es mir nur die BOs zumüllt. Damit läuft es. Nur die Tatsache dass es läuft tröstet mich nicht. Gemein ist, dass das Problem in Produktion noch früher auftritt. D.h. in Entwicklung läuft es und in Produktion nicht mehr.

Ich bin schon gespannt was für Probleme sich noch ergeben werden und ob das ganze nicht eine Vollgasfahrt in die Sackgasse ist. Das Problem hier steht bei mir so da, wie das LifeCycle Problem, welches ich am 24.07. gepostet habe, bei dem die ActionMethod und PostConstruct unter bestimmten Bedingungen in der umgekehrten und damit falschen Reihenfolgen aufgerufen werden.

7

Das ist ein seltsames Verhalten, bei den selben Binary Files? Kompilierte Class Files scheren sich ja nicht darum, ob auf Java Ebene eine Zeile Quellcode mehr oder weniger existiert.
Kannst du herausfinden, ob die Klasse vom Classloader geladen wird? Existiert die Klasse im Ziel-Jar?

8

[quote=inv_zim;138488]Das ist ein seltsames Verhalten, bei den selben Binary Files? Kompilierte Class Files scheren sich ja nicht darum, ob auf Java Ebene eine Zeile Quellcode mehr oder weniger existiert.
Kannst du herausfinden, ob die Klasse vom Classloader geladen wird? Existiert die Klasse im Ziel-Jar?[/quote]
Das alles kann ich, im Moment, leider nicht mit Sicherheit sagen. Sobald ich etwas Zeit finde spiele ich damit ausführlich herum und werde berichten.

9

Hey @dpo

Hast du hier noch mal ein Update?

10

Noch nicht. Ich werde noch nachforschen müssen, da mein Vertrauen in die Technik gerade sehr leidet. Ist ja nicht die einzige schwerwiegende macke in JSF2.2 welche mir gerade um die Ohren fliegt.

11

Jetzt ist mir das ganze wieder um die Ohren geflogen. Im WAR existiert die Class.

Wie kann ich über prüfen ob die Class com Classloader geladen wird?

Die Exception sieht ein wenig anders aus, aber die Aussage ist die gleiche:

 javax.el.PropertyNotFoundException: /mdeAuftrag.xhtml @36,124 value="#{myBean.simpleTexteingabe}": Target Unreachable, identifier 'myBean' resolved to null
... bla ... bla ...
Caused by: javax.el.PropertyNotFoundException: Target Unreachable, identifier 'myBean' resolved to null
... bla ... bla ...```
12

Wenn sowas hier in der in der ManagedBean steht, dann ist es vorbei. Probleme gibt es immer nur, wenn Stream und Lambda verwendet werden.

Auftrag a = itAuftrag.next();```

Wenn ich dagegen in einer ForSchleife die AuftragList durchlaufe und darin jeden Auftrag mit den Methoden überprüfe, welche schon in Java6 vorhanden waren, dann gibt es keine Probleme. Wenn ich den o.g. Code in ein BO schreibe und delegiere, dann funktioniert es auch. Der Code hat im BO nichts zu suchen, da es eine reine Angelegenheit der View ist. Ich bin ja froh, dass es einfach nur nicht funktioniert. So werden wenigstens keine Daten und Prozesse gefährdet. 

Warum passiert das? Ich meine das es doch tatsächlich daran liegt, dass EE6 zu Java8 nicht vollständig kompatibel ist. Beknackt ist trotzdem, dass es einmal funktioniert und dann wieder nicht.