2012-05-01 10 views
6

La specifica dice che il contenitore CDI rimuove un SFSB quando il contesto dell'oscilloscopio sta per essere distrutto. Come rimuove esattamente l'EJB? Non sembra che chiami il metodo annotato con @Remove.In che modo CDI rimuove il bean di sessione con stato?

@Stateful 
public class CustomerDAOImpl implements CustomerDAO { 
    @PreDestroy 
    public void onDestroy() { 
     //This is getting called as expected 
    } 
    @Remove 
    public void deleteMyBean() { 
     //This is not getting called! 
    } 
} 

Quindi, CDI sta facendo tecnicamente quello che dice la specifica. La domanda è: come riesce a chiedere al contenitore EJB di rimuovere l'istanza? Grazie.

risposta

2

Come covener dice che questo viene fatto utilizzando un'API EJB specifica dell'implementazione, che non fa parte dell'API standard EJB.

Come dice covener, chiamare @Remove è NON il modo corretto per procedere. I metodi @Remove sono chiamati dal codice degli utenti e indica allo il contenitore EJB per rimuovere il bean. Se vuoi una richiamata quando l'EJB viene rimosso, usa @PreDestroy.

-1

Il metodo con annotazione @Remove deve essere chiamato esplicitamente dal client, quindi il contenitore chiamerà implicitamente il metodo annotato con @PreDestroy, se esiste. Successivamente, l'istanza del bean sarà pronta per la garbage collection.

Questo è l'unico metodo del ciclo di vita che il client può controllare, tutti gli altri metodi sono controllati dal contenitore.

+0

Sì, questo è il comportamento normale. Ma in che modo il contenitore CDI rimuove l'EJB? Sta usando un qualche tipo di API non documentata per chiedere al contenitore EJB di fare la rimozione? – RajV

+0

@RajV Non sono stato in grado di localizzarlo nelle specifiche, ma puoi trovare informazioni utili nell'esercitazione su Java EE, in "Ciclo di vita di un sorso di Stateful Session Bean" all'indirizzo http://docs.oracle.com/javaee/5 /tutorial/doc/bnbmt.html –

+0

@downvoter Cura di spiegare per -1 –

3

Penso che il contenitore CDI abbia bisogno di un gancio nel contenitore EJB per chiedergli di "fare ciò che si farebbe se fosse stato appena completato un metodo @Remove". Osservando le specifiche EJB, EJB 2.1 aveva un meccanismo per questo nelle interfacce che dovevi estendere.

Per ovvi motivi, il contenitore che chiama un metodo annotato @Remove arbitrario per l'effetto collaterale è piuttosto sconsigliato.

+0

+1, ma come pignolo, il contenitore possiede l'implementazione di EJBObject (che ha .remove, che è fondamentalmente ciò che CDI vuole usare), ma il bean implementa SessionBean. –

+0

Questa non è una risposta, ma una speculazione. Se effettivamente ci fosse un tale gancio, sarà altamente specifico del venditore. Come può un'implementazione come Weld farlo in modo generico. – RajV

+0

La domanda non è se il modo di saldatura lo rende portabile. Weld richiede specificamente il contenitore per fornire tutti i tipi di implementazioni di interfacce, incluso SessionObjectReference # remove – covener

Problemi correlati