Essa eh justamente uma grande vantagem que eu acho em usar o Lomboz. Na verdade o lomboz ira processar esse seu EJB (usando o xdoclet) e fara uma nova classe, que estende a sua classe, adicionando os metodos que voce nao criou, como ejbPassivate, blablabla.
Os containers, por sua vez, tambem fazem esse trabalho de estender seu EJB, no momento do deploy, para ativar as funcionalidade que voce definiu de modo declarativo no seu ejb-jar.xml. Essa estensao que os container fazem pode ser por AOP, por geracao de novas classes e compilacao, isso fica a cargo do container.
Para ficar um pouco mais claro, imaginemos um metodo criarUsuario num StatelessSessionBean. No ejb-jar.xml voce define que ele eh transacional, e que precisa de um usuario administrador para executar esse metodo. Uma possibilidade para o container, no momento do deploy seria sobrescrever o seu metodo criarUsuario da seguinte forma (em pseudo codigo):
public void criarUsuario(args) {
isUserInRole("admin");
beginTransaction;
super.criarUsuario();
endTransaction;
}
Eh por isso inclusive, que muitas pessoas defendem a substituicao de application servers por mecanismos de AOP, pois bastaria enxertar chamadas de metodos que verifiquem as necessidades do Componente, sem ter que comprar um Container que custa os tubos.
Espero que tenha esclarecido um pouco as “magicas” que acontecem com seus EJBs, dentro dos containers J2EE.
