@ManagedProperty jest nullem

0

Cześć,

mam problem z użyciem @ManagedProperty, mam taki kod:

import java.io.Serializable;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import pl.pluta.multikino.db.MySql;

@ManagedBean(name = "mySqlBean", eager = true)
@SessionScoped
public class MySqlBean implements Serializable {
    private final MySql mySql;
    
    public MySqlBean() {
        mySql = new MySql();
        mySql.connect();
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        
        mySql.close();
    }

    public MySql getMySql() {
        return mySql;
    }
}
import java.io.Serializable;
import java.util.HashMap;
import java.util.List;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.ManagedProperty;
import javax.faces.bean.SessionScoped;
import pl.pluta.multikino.bean.MySqlBean;
import pl.pluta.multikino.dao.FilmDAO;
import pl.pluta.multikino.model.Film;
import pl.pluta.multikino.model.FilmStatus;
import pl.pluta.multikino.util.MessageUtil;

@ManagedBean (name = "filmBean")
@SessionScoped
public class FilmBean implements Serializable{
    @ManagedProperty(value = "#{mySqlBean}")
    private MySqlBean mySqlBean;
    
    @ManagedProperty(value = "#{logiBean}")
    private LoginBean loginBean;
    
    private FilmDAO filmDAO;
    private List<Film> films;
    
    private String title;
    private String description;
    private String status;
    
    private Film editedFilm;
    
    public FilmBean() {
        filmDAO = new FilmDAO(mySqlBean.getMySql());
    }
    
    ...

    public MySqlBean getMySqlBean() {
        return mySqlBean;
    }

    public void setMySqlBean(MySqlBean mySqlBean) {
        this.mySqlBean = mySqlBean;
    }
}

W konstruktorze FilmBean pole mySqlBean == null. Ma ktoś może jakiś pomysł?

Wielkie dzięki za pomoc :)

0

A czego się niby spodziewasz? o_O Kiedy wg ciebie kontener moze wstrzyknąć zależności? Przed czy po utworzeniu obiektu? Gdzie tu jakaś logika? Rozumiesz chyba ze kontener nie robi zadnej magii tylko po prostu tworzy obiekt a potem ustawia mu potrzebne zależności?

Nie do końca rozumiem też logikę tego kodu. DAO to powininen być singletonowy serwis utworzony raz przy starcie aplikacji i wstrzykiwany tam gdzie jest potrzebny. A ty tworzysz nowy obiekt dao dla każdej sesji każdego użytkownika. Czemu? Tworzenie w ten sposób bezstanowych serwisów powinno być karane...

0

Cześć,

na początku dzięki za szybką odpowiedź. Odpowiedź jest prosta, jeżeli chodzi o JEE to jestem totalnie zielony, pomagam komuś z doskoku i oto efekty :)

  1. Byłem przekonany, że jeżeli bean nie istnieje to zostanie stworzony w momencie wstrzyknięcia, z tego co napisałeś to się mylę. Ogólnie zaczyna się od tego, że nie wiem za bardzo w jaki sposób przekazy DAO dostęp do sql. Tworząc MySql jako singleton obawiam się o wielowątkowość (instancja klasy MySql ma jedno połączenie). W takim razie jak to powinno być zorganizowane? Szukałem jakiś zaproponowanych rozwiązań ale nic ciekawego mi się nie rzuciło.

  2. To co napisałeś o DAO jako singletonach ma sens. Jednak jak wymusić, żeby zostały stworzone podczas startu app? Przekazywanie ich powinno się odbywać przez wstrzykiwanie? Można prosić jakiś przykład?

Wielkie dzięki. Pozdrawiam.

0
  1. Nie do końca. Zauważ że kontener musi to jakoś zrobić. Tam nie ma magii. Kontener odpala konstruktor a potem settery. Siła rzeczy w trakcie działania konstruktora pola nie są ustawione.
  2. Lepiej byłoby użyć jpa albo puli wątków do bazy danych ale bez tego masz tylko ograniczenie wydajności bo obiekty bezstanowe są thread safe zawsze.
  3. Masz przecież application scoped managed beans, masz singletonowe EJB...
0
  1. Ok, w takim razie, da się jakoś zorganizować taki przypadek jak napisałem w pierwszym poście?
  2. Niestety projekt musi być z użyciem JDBC, myślę, że pula połączeń to dobry wybór.
  3. Ok, jest to jakieś rozwiązanie

Pozdrawiam

1
  1. Da się za pomocą @PostConstruct. Anotujesz w ten sposób metodę która zostanie wywołana PO konstruktorze obiektu i PO wstrzyknięciu zależności, ale jeszcze zanim obiekt stanie się "dostępny" dla klienta. Ale wydaje mi się że to nie jest dobra droga. Bo tworzysz w ten sposób całą masę tych bezstanowych DAO, mimo że w rzeczywistości potrzebujesz tylko jednego. Szczególnie że one wszystkie i tak pomykają na tym samym połączeniu do bazy. Swoją drogą współdzielenie połączenia do bazy w ten sposób jest raczej słabe ;]

1 użytkowników online, w tym zalogowanych: 0, gości: 1