2012-05-14 16 views
6

Ho un semplice (webprofile) EJB 3.1 Applicazione e cercare non determinare l'utente corrente all'interno di un @ApplicationScoped CDI Bean, per cui uso:NullPointerException in sessionContext.getCallerPrincipal()

Principal callerPrincipal = this.sessionContext.getCallerPrincipal() 

che funziona bene (così ho può determinare il nome dell'utente corrente).

Ma dopo ogni eccezione in qualsiasi (altro) EJB questa chiamata non funziona più (ho bisogno di riavviare il Server)! Invece di restituire il principal del chiamante, il metodo lancia questa eccezione.

Caused by: java.lang.NullPointerException 
at com.sun.ejb.containers.EJBContextImpl.getCallerPrincipal(EJBContextImpl.java:421) 
at de.mytest.service.CurrentUserService.getCurrentUserId(CurrentUserService.java:102) 

Qualcuno può darmi un suggerimento che cosa sto facendo male?


dettagli di implementazione:

Server Glassfish 3.1.2

CurrentUserService:

@ApplicationScoped 
public class CurrentUserService { 

    @Resource 
    private SessionContext sessionContext; 

public long getCurrentUserId() { 

     if (this.sessionContext == null) { 
      throw new RuntimeException("initialization error, sessionContext must not be null!"); 
     } 

/*line 102 */  Principal callerPrincipal = this.sessionContext.getCallerPrincipal(); 
     if (callerPrincipal == null) { 
      throw new RuntimeException("callerPrincipal must not be null, but it is"); 
     } 

     String name = callerPrincipal.getName(); 
     if (name == null) { 
      throw new RuntimeException("could not determine the current user id, because no prinicial in session context"); 
     } 

     return this.getUserIdForLogin(name);   
    } 

L'EJB facad che resistono tra il controller Volti e il Servizio

@Stateless 
@RolesAllowed("myUser") 
public class TeilnehmerServiceEjb { 

    @Inject 
    private CurrentUserService currentUserService; 

    public long currentUserId() { 
     return = currentUserService.getCurrentUserId(); 
    } 
} 
CDI

web.xml

<security-constraint> 
    <web-resource-collection> 
     <web-resource-name>All Pages</web-resource-name> 
     <url-pattern>/*</url-pattern> 
    </web-resource-collection> 
    <auth-constraint> 
     <role-name>myUser</role-name> 
    </auth-constraint> 
</security-constraint> 

<login-config> 
    <auth-method>BASIC</auth-method> 
    <realm-name>mySecurityRealm</realm-name> 
</login-config> 

GlassFish-web.xml

<security-role-mapping> 
    <role-name>myUser</role-name> 
    <group-name>APP.MY.USER</group-name> 
</security-role-mapping> 
+1

Perché non farcela SessionScoped? –

+1

Questo sembra un difetto Glassfish. –

+0

Se crei un'app che esegue solo ciò che stai descrivendo puoi riprodurre il comportamento? Se è così, ti incoraggio a presentare un bug. – Preston

risposta

3

Il motivo per cui non funziona è perché il vostro oggetto SessionContext è dichiarato come una variabile globale e dal momento che si sta utilizzando @ApplicationScope, l'ititializzazione di tale risorsa tramite IoC verrà eseguita una sola volta quando viene creata l'app.

Se si desidera mantenere il bean come @ApplicationScope, si consiglia di provare ad accedere a SessionContext ogni volta che è necessario manualmente dal metodo che esegue l'azione, ma invece di IoC utilizzare manualmente l'API JNDI. Vedere l'esempio come vedere caldo per eseguire una ricerca JNDI per accedere a una risorsa manualmente utilizzando:

public long getCurrentUserId() { 
     //.. 
    try { 
      InitialContext ic = new InitialContext(); 
      SessionContext sessionContext=(SessionContext) ic.lookup("java:comp/env/sessionContext"); 

      System.out.println("look up injected sctx: " + sessionContext); 

    //Now do what you want with the Session context: 
     Principal callerPrincipal = sessionContext.getCallerPrincipal(); 
    //.. 
     } catch (NamingException ex) { 
      throw new IllegalStateException(ex); 
     } 
//.. 

} 

Se siete interessati a conoscere più modi di accesso alla SessionContext, date un'occhiata a questo link dove ho trovato che pezzo di codice presentato:

http://javahowto.blogspot.com/2006/06/4-ways-to-get-ejbcontext-in-ejb-3.html

spero che questo aiuta

+0

Posso confermare che hai ragione: ha funzionato perfettamente dopo il passaggio a '@ Stateless' – Ralph

Problemi correlati