Limitações do @EJB?

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

Pessoal a anotação para declarar um EJB tem limitação de onde pode ser usada, pq quando uso ela no meu managed bean do JSF funciona tranq, agora se criar uma classe a parte(BusinessDelegate) e dentro dele chamar @EJB e chamar um session bean o EJB não é injetado.

Alguem sabe o que pode ser?

rafaelmeireles wrote:Pessoal a anotação para declarar um EJB tem limitação de onde pode ser usada, pq quando uso ela no meu managed bean do JSF funciona tranq, agora se criar uma classe a parte(BusinessDelegate) e dentro dele chamar @EJB e chamar um session bean o EJB não é injetado.

Alguem sabe o que pode ser?

A anotação @EJB só pode ser usada em ambientes que o Conteiner possa gerenciar, no caso Servlets e Managed Beans (deve ter outros).

No seu caso o Delegate nao sofre controle do Conteiner.

Neste caso o Delegate nao é necessário pois o acoplamento dos componentes nao se dará por delegação, mas sim por injeção.

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

valeu kra pela dica.

Só que nao acho interessante o managed bean acessar meus SessionFacade direto, neste caso so poderei fazer se for com lookup?

rafaelmeireles wrote:valeu kra pela dica.

Só que nao acho interessante o managed bean acessar meus SessionFacade direto, neste caso so poderei fazer se for com lookup?

Daí sim, vc terá que fazer lookup no Delegate, dessa forma vc perde a facilidade do uso de injeção de dependencia.

Porque vc quer colocar mais uma classe para apenas chamar teus Façades? o Menaged Bean vai apenas conhecer a interface do Façade (remota ou local).

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

pq entendo que dessa forma o managhed bean não ficaria a mercer de mundanças na camada de negocio.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

rafaelmeireles wrote:pq entendo que dessa forma o managhed bean não ficaria a mercer de mundanças na camada de negocio.

Aplicação em Java não é lasanha, que fica melhor quanto mais camadas você põe, a partir do EJB 3, um Delegate se torna "deprecated".

Além disso, sua argumentação é injustificável pois o managed bean conhece apenas a interface, não a regra de negócio que implementa a interface. É claro que pode ficar "à mercê de mudanças" da interface, mas isso nem o Delegate resolve.

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

e quanto a questão das excecoes, que quem transformava para excecoes nao EJB era o delegate como fica?

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

sem falar do alto acoplamento entre as camadas de view e negocio.

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

rafaelmeireles wrote:e quanto a questão das excecoes, que quem transformava para excecoes nao EJB era o delegate como fica?

Não entendi, você camuflava a RemoteException? O managedBean pode ter um try-catch, onde caso uma exceção seja capturada, uma string diferente seja retornada, redirecionando pra uma página de erro. Alías, é o melhor lugar pra capturar exceções e tomar providências adequadas.

rafaelmeireles wrote:sem falar do alto acoplamento entre as camadas de view e negocio.

Managed Bean não é View! Seria acoplamento entre view e negócio se você tivesse, na sua página jsp, uma declaração entre <% e %> onde você chamasse seu EJB.

Além disso, o Managed Bean tem a INTERFACE, não a CLASSE do EJB, portanto, mais uma vez, a sua teoria de alto acoplamento não procede.

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

antes do Java EE 5 poderiamos usar um ServiceLocator por exemplo e a partir dele usar somente as interfaces do EJB que alias sempre se trbalhou com as interfaces, vc acha então que isso é baixo acoplamento?

Me expressei mal quanto a VIEW no managed bean

GUJ Ranger Membro desde: 04/07/2007 18:28:58 Mensagens: 975 Offline

rafaelmeireles wrote:antes do Java EE 5 poderiamos usar um ServiceLocator por exemplo e a partir dele usar somente as interfaces do EJB que alias sempre se trbalhou com as interfaces, vc acha então que isso é baixo acoplamento?

Me expressei mal quanto a VIEW no managed bean

Até a versão 2.1 do EJB, precisávamos sim de um Service Locator e de um Business Delegate, o problema não está no fato do Managed Bean (ou de qualquer cliente) de conhecer a interface do EJB (até porque isso é inevitável); o problema está no cliente conhecer detalhes de container J2EE como lookup e outras bizarrices. Assim um padrão que fizesse o cliente não conhecer o container era desejável e reduzia o acoplamento para apenas a sua interface de negócio EJB.

Com a introdução do EJB 3, o container passa a fazer o lookup, tomando o lugar do Delegate, e o cliente, mesmo sem patterns, está acoplado a apenas à interface de negócio, e nesse caso o uso de Business Delegate não acrescenta nem reduz o acoplamento. No Java EE, o baixo acoplamento "vem de fábrica".

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

Com a introdução do EJB 3, o container passa a fazer o lookup, tomando o lugar do Delegate

kra encapsular o lookup era função do Service Locator!

o problema não está no fato do Managed Bean (ou de qualquer cliente) de conhecer a interface do EJB (até porque isso é inevitável);

inevitavél... isso é exatamente o que o delegate faz!
a menos que se implemente o delegate como um EJB, ai é demais...

JavaChild Membro desde: 14/07/2006 09:45:21 Mensagens: 128 Offline

O problema é se vc nao tiver usando no mesmo container. Nesse caso o lookup é inevitável.

rafaelmeireles wrote:antes do Java EE 5 poderiamos usar um ServiceLocator por exemplo e a partir dele usar somente as interfaces do EJB que alias sempre se trbalhou com as interfaces, vc acha então que isso é baixo acoplamento?

Me expressei mal quanto a VIEW no managed bean

Mesmo que vc use o Business Delegate, vc é obrigado a conhecer as interfaces do teu EJB.

Nao entendi direito quando vc diz que o uso de interfaces nao oferece baixo acoplamento.

Com a injeção a construcao de um Service Locator é totalmente desnecessária, pois ele vai exercer uma funcão que como disse o Leonardo ja "Vem de fábrica".

Por debaio dos panos o Conteiner vai fazer lookup e tudo, mas é o conteiner o responsável por fazer isso.

Agora se vc gosta de usar ServiceLocator, ou por exemplo tem um sistema legado que precisa usar isso, use a vontade.

O ideal é que, ao usar o Java EE 5 seja repensada a arquitetura J2EE usada, muitos padrões não são mais necessários.

JavaTeenager Membro desde: 13/01/2004 16:12:22 Mensagens: 151 Offline

Mesmo que vc use o Business Delegate, vc é obrigado a conhecer as interfaces do teu EJB

no cliente de forma alguma, ele apenas conhecera o delegate.

Nao entendi direito quando vc diz que o uso de interfaces nao oferece baixo acoplamento

quiz dizer que só usar interfaces não te dara um baixo acoplamento, pq no caso dos EJB´s ficara explicito o seu uso por causa de @EJB

Com a injeção a construcao de um Service Locator é totalmente desnecessária, pois ele vai exercer uma funcão que como disse o Leonardo ja "Vem de fábrica".

O problema disso é que fica tudo amarrado a EJB uma vez que em POJO´s a injeção não é suportada

O ideal é que, ao usar o Java EE 5 seja repensada a arquitetura J2EE usada, muitos padrões não são mais necessários.

Tem alguma fonte de pesquisa tipo um catalogo de padroes da SUN para o java EE 5?

Notícias, artigos e o maior fórum brasileiro sobre Java