La regola base degli EJB 3.0 è che si possono specificare le informazioni di configurazione sia a livello di annotation (quindi nel codice dell'Ejb) sia nel deployment descriptor (il file ejb-jar.xml).
Nel caso in cui una informazione sia specificata sia a livello di metodo EJB che a livello di deployment descriptor è preminente quest'ultimo.
Con una particolarità (che mi ha fregato...) : se nell'xml non è specificato il valore <method-param> allora tutti i metodi con il nome specificato nel file xml (inclusi i metodi con overload) sono guidati nelle impostazioni dal file Xml e non dalle loro proprie annotation.
Esempio:
@Stateless
public class TestBean implements TestInterface
{
@RolesAllowed("user")
public void doStuff(String str){ }
public void doStuff(){ }
}
Snippet del deployment descriptor:
<method-permission>
<role-name>customer</role-name>
<method>
<ejb-name>EnthuBean</ejb-name>
<method-name>doStuff</method-name>
</method>
</method-permission>
In questo caso soltanto il ruolo customer può accedere i due metodi.
Nel caso in cui una informazione sia specificata sia a livello di metodo EJB che a livello di deployment descriptor è preminente quest'ultimo.
Con una particolarità (che mi ha fregato...) : se nell'xml non è specificato il valore <method-param> allora tutti i metodi con il nome specificato nel file xml (inclusi i metodi con overload) sono guidati nelle impostazioni dal file Xml e non dalle loro proprie annotation.
Esempio:
@Stateless
public class TestBean implements TestInterface
{
@RolesAllowed("user")
public void doStuff(String str){ }
public void doStuff(){ }
}
Snippet del deployment descriptor:
<method-permission>
<role-name>customer</role-name>
<method>
<ejb-name>EnthuBean</ejb-name>
<method-name>doStuff</method-name>
</method>
</method-permission>
In questo caso soltanto il ruolo customer può accedere i due metodi.
Nessun commento:
Posta un commento