Jak ponownie wstrzyknąć transient @ ManagedProperty przy deserializacji?

Question

Używam Spring i JSF 2 do tworzenia aplikacji internetowych. Przedmiotem działalności są przechowywane w pojemniku na wiosnę, a ja je wstrzykiwać w Managed Beans pomocą @ManagedProperty, tak:

@ManagedBean 
@ViewScoped 
public class SomeMB implements Serializable { 
    private static final long serialVersionUID = 1L; 

    @Getter @Setter 
    @ManagedProperty("#{someService}") 
    private SomeService someService; 
    // ... 

Problem polega na tym, trzymam coraz NotSerializableException dla klasy od wiosny (ServiceLocatorFactoryBean), który jest używany przez komponent bean SomeService SomeService.

Jeśli zrobię to transient, w jaki sposób mogę wykonać ponowne wstrzyknięcie po deserializacji?

Albo, jakie byłyby inne sposoby rozwiązania tego problemu?

Czytałem tutaj kilka innych podobnych pytań, ale nie mogłem znaleźć żadnego rozwiązania tego problemu.

Answer 1

Zamiast wstrzykiwanie fasolę Wiosenne pośrednictwem EL w @ManagedProperty adnotacji (wykonywane na ManagedBean inicjalizacji), uzyskanie ziarna oceniające EL przy starcie.

Z takim podejściem, to co ziarna JSF powinna wyglądać następująco:

@ManagedBean 
@ViewScoped 
public class SomeMB implements Serializable { 
    private static final long serialVersionUID = 1L; 

    private static SomeService someService() { 
     return SpringJSFUtil.getBean("someService"); 
    } 
    // ... 

a klasa użyteczności SpringJSFUtil.java że dostaje fasoli poprzez EL:

import javax.faces.context.FacesContext; 

public class SpringJSFUtil { 

    public static <T> T getBean(String beanName) { 
     if (beanName == null) { 
      return null; 
     } 
     return getValue("#{" + beanName + "}"); 
    } 

    @SuppressWarnings("unchecked") 
    private static <T> T getValue(String expression) { 
     FacesContext context = FacesContext.getCurrentInstance(); 
     return (T) context.getApplication().evaluateExpressionGet(context, 
       expression, Object.class); 
    } 
} 

Eliminuje właściwość Spring bean (kosztem wykonania kilku innych ocen EL), unikając w ten sposób wszystkich problemów związanych z serializacją posiadania właściwości na pierwszym miejscu.

To samo podejście, używając OmniFaces:

W moim rzeczywisty kod, używam metody z utility class dostępny od OmniFacesevaluateExpressionGet(String expression). Tak więc, dla tych z Was, którzy używają go też, to właśnie mój kod naprawdę wyglądać następująco:

import static org.omnifaces.util.Faces.evaluateExpressionGet; 

@ManagedBean 
@ViewScoped 
public class SomeMB implements Serializable { 
    private static final long serialVersionUID = 1L; 

    private static SomeService someService() { 
     return evaluateExpressionGet("#{someService}"); 
    } 
    // ... 

_{Zauważ, że tutaj metoda dostaje pełną EL („# {wyrażenie}”), a nie tylko na wiosnę nazwa fasoli (lub otrzymasz wyjątek ClassCastException).}

Answer 2

Dobrze o tym pamiętać z podręcznika sprężyna ( link to spring):

Konstruktor opartych lub seter opartej DI?

Ponieważ można mieszać DI, zarówno konstruktora, jak i Settera, jest to dobra zasada, aby używać argumentów konstruktora dla obowiązkowych zależności i ustawiających dla zależności opcjonalnych. Zauważ, że użycie @ Adnotacji wymaganej na setera może być użyte do ustalenia zależności wymaganych przez ustawiacze.

Zespół wiosenny ogólnie opowiada się za zastrzykiem ustawiającym, ponieważ duża liczba argumentów konstruktora może stać się nieporęczna, szczególnie gdy właściwości są opcjonalne. Metody setera również sprawiają, że obiekty tej klasy są zdolne do ponownej konfiguracji lub ponownego wtrysku później. Zarządzanie przez JMX MBeans jest przekonującym przykładem użycia.

Niektórzy puryści preferują zastrzyki oparte na konstruktorze. Dostarczenie wszystkich zależności obiektów oznacza, że ​​obiekt jest zawsze zwracany do klienta (wywoływania) w całkowicie zainicjalizowanym stanie. Wadą jest to, że obiekt staje się mniej podatny na rekonfigurację i ponowne wstrzyknięcie.

Użyj DI, który najlepiej pasuje do konkretnej klasy. Czasami, gdy zajmujesz się zajęciami osób trzecich, do których nie masz źródła, wybór jest dla Ciebie. Starsza klasa może nie ujawniać żadnych metod ustawiających, a zatem wtrysk konstruktora jest jedynym dostępnym DI.

Answer 3

Wypróbuj @Scope (wartość = BeanDefinition.SCOPE_SINGLETON, proxyMode = ScopedProxyMode.INTERFACES) w usłudze Spring @Service. To powinno wstrzyknąć serializowalny obiekt proxy do zarządzanego komponentu bean, który przeniesie usługę po uzyskaniu dostępu po deserializacji.

Answer 4

Dla tych, którzy śledzą - miałem podobny problem z wstrzykniętym zasobem ResourceBundle. Korzystanie część odpowiedzi BalusC jest, zrobiłem co następuje:

@ManagedProperty(value="#{myBundle}") 
private transient ResourceBundle myBundle; 

private Object readResolve() { 
    myBundle = FacesContext.getCurrentInstance().getApplication() 
     .evaluateExpressionGet(FacesContext.getCurrentInstance(), "#{myBundle}", 
     ResourceBundle.class); 
    return this; 
} 

ten sposób EL oceniana jest tylko wtedy, gdy udało fasola jest rozszeregować.