2009-05-13 15 views
5

Ho difficoltà ad accedere a un bean di sessione stateful (SFSB) da un client dell'applicazione. Sto usando JBoss 5.0.1.GA. Il client dell'applicazione e gli EJB sono entrambi pacchettizzati in un EAR che distribuisce e ho altri client applicativi che funzionano senza problemi. Finora, ho utilizzato solo bean di sessione stateless (SLSB), ma per quanto riguarda la funzionalità di inizializzazione, le differenze tra SLSB e SFSB non dovrebbero influire sul modo in cui è possibile accedervi da un client dell'applicazione.EJB 3: Accesso a un bean di sessione stateful da un client applicativo

La struttura delle classi/interfacce:

@Local public interface A {...} 

@Stateless public class ABean implements A {...} 

@Remote public interface B {...} 

@Stateful public class BBean implements B { 
    @EJB private A anInstanceOfA; 

    @PostConstruct private void init() { 
     this.anInstanceOfA.someMethod(); 
    } 
} 

L'applicazione client è eseguito mediante il "AppClient-launcher", come descritto in "How to use an application client in JBoss 5". Facendo la ricerca di "BBean" funziona bene finché non viene chiamato someMethod() sul (locale) ABean durante l'esecuzione di init(). Durante la chiamata, il contenitore genera una InvalidStateException ("Chiamata locale: contesto di sicurezza è null") (come causa principale). Quando cambio il bean stateful in un bean senza stato, tutto funziona bene (eccetto, ovviamente, che lo stato non è preservato). È interessante notare che posso utilizzare esattamente lo stesso SFSB da un'applicazione Web (in un bean gestito JSF).

Sto facendo qualcosa di sbagliato? Come dovrei usare un SFSB da un client applicativo?

Non ho trovato nulla di utile su questo particolare problema finora. L'eccezione è menzionata in un contesto simile in [#JBAS-4317] Security Context over the invocation, ma considerando che è contrassegnato come fatto ed è stato risolto in JBoss 5.0.0.Beta3, sembra che non sia lo stesso problema.

risposta

1

Anche se mi piace ancora di sapere perché il mio setup originale funziona perfettamente per i bean di sessione senza stato, ma non per session bean stateful, ecco la soluzione che ho trovato:

Il web-application che è anche confezionato in EAR fa la sua autenticazione tramite JAAS. Per questo ho configurato un dominio di sicurezza nella JBoss login-config.xml, che assomiglia a questo:

<application-policy name="My-SD"> 
    <authentication> 
     <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required"> 
      <module-option name="unauthenticatedIdentity">guest</module-option> 
      <module-option name="dsJndiName">java:/myDS</module-option> 
      <module-option name="principalsQuery">SELECT PASSWORD FROM LOGIN WHERE LOGIN = ? AND STATUS > 0</module-option> 
      <module-option name="rolesQuery">SELECT ROLE, 'Roles' FROM USER_ROLE WHERE LOGIN = ?</module-option> 
     </login-module> 
    </authentication> 
</application-policy> 

Ho usato questo dominio di protezione in JBoss-web.xml della web-application, così come nel Jboss.xml del progetto EJB, anche se in realtà lo utilizzo solo nell'app Web (gli EJB sono accessibili senza autenticazione).

Per risolvere il problema con l'accesso all'SFSB, ho dovuto rimuovere il mio dominio di sicurezza da jboss.xml nel progetto EJB. Questo fa quindi utilizzare a JBoss il dominio di sicurezza predefinito che sembra fare la cosa giusta e il mio client applicativo finalmente può accedere e utilizzare l'SFSB.

0

Il motivo è disponibile nel EJB 3.0 Core Specification, sezione 12.4. Ci dice

I metodi dell'intercettatore di callback del ciclo di vita vengono richiamati in una transazione e un contesto di sicurezza non specificati.

hth,
- Martin

+1

informazioni interessanti. Tuttavia, non sono sicuro di come questo spieghi il comportamento, soprattutto perché "funziona" in un bean senza stato e il problema si verifica solo quando ho usato il mio dominio di sicurezza. Comunque, dal momento che non ho più nulla a che fare con il progetto e da allora non ho fatto nessuno sviluppo Java EE, non sono davvero motivato a scoprire come funzioni effettivamente questa roba. Grazie comunque! –

Problemi correlati