Arquivo Discussoes de Programacao e Tecnologia 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?
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.
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?
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).
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.
e quanto a questão das excecoes, que quem transformava para excecoes nao EJB era o delegate como fica?
sem falar do alto acoplamento entre as camadas de view e negocio.
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.
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.
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 
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”.
kra encapsular o lookup era função do Service Locator!
inevitavél… isso é exatamente o que o delegate faz!
a menos que se implemente o delegate como um EJB, ai é demais…
O problema é se vc nao tiver usando no mesmo container. Nesse caso o lookup é inevitável.
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.
no cliente de forma alguma, ele apenas conhecera o delegate.
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
O problema disso é que fica tudo amarrado a EJB uma vez que em POJO´s a injeção não é suportada
Tem alguma fonte de pesquisa tipo um catalogo de padroes da SUN para o java EE 5?
no cliente de forma alguma, ele apenas conhecera o delegate.
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
O problema disso é que fica tudo amarrado a EJB uma vez que em POJO´s a injeção não é suportada
Tem alguma fonte de pesquisa tipo um catalogo de padroes da SUN para o java EE 5?
Conceitualmente, não existe diferença entre conhecer a interface do Delegate e conhecer a interface do EJB, os dois são semelhantes! Claro, são classes diferentes, mas seus métodos são parecidíssimos. Por isso, não existe nenhum “desacoplamento” quando você troca o Delegate pela interface EJB. Por isso, minha afirmação de que é inevitável que o cliente conheça a interface do negócio continua válida.
Uma anotação é apenas uma marcação, não é porque você põe um @EJB em cima de um atributo que ele vai ficar acoplado ao container de EJB, ele vai ficar acoplado apenas a um anotation, só isso. O acoplamento se dá através de conhecimentos de outros objetos ao seu redor, quanto mais conhecer mais acoplado.
A interface EJB é um POJI (Plain Old Java Interface), se você colocar um cliente e a classe de implementação do EJB fora do contexto Java EE e dentro do contexto Java SE, os dois conseguem se comunicar se você colocar um setter dentro do cliente com a interface Local do EJB como parâmetro, e invocar esse setter passando uma instância da classe de implementação. Todo isso pra dizer o seguinte, o cliente não está amarrado a um EJB, pois se pode injetar a implementação.
Meu, de boa, o melhor é colocar a interface EJB dentro do managed bean. O framework Seam faz isso e Java EE te estimula a fazer isso, então pra que ficar negando?
no cliente de forma alguma, ele apenas conhecera o delegate.
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
O problema disso é que fica tudo amarrado a EJB uma vez que em POJO´s a injeção não é suportada
Tem alguma fonte de pesquisa tipo um catalogo de padroes da SUN para o java EE 5?
Conceitualmente, não existe diferença entre conhecer a interface do Delegate e conhecer a interface do EJB, os dois são semelhantes! Claro, são classes diferentes, mas seus métodos são parecidíssimos. Por isso, não existe nenhum “desacoplamento” quando você troca o Delegate pela interface EJB. Por isso, minha afirmação de que é inevitável que o cliente conheça a interface do negócio continua válida.
Uma anotação é apenas uma marcação, não é porque você põe um @EJB em cima de um atributo que ele vai ficar acoplado ao container de EJB, ele vai ficar acoplado apenas a um anotation, só isso. O acoplamento se dá através de conhecimentos de outros objetos ao seu redor, quanto mais conhecer mais acoplado.
A interface EJB é um POJI (Plain Old Java Interface), se você colocar um cliente e a classe de implementação do EJB fora do contexto Java EE e dentro do contexto Java SE, os dois conseguem se comunicar se você colocar um setter dentro do cliente com a interface Local do EJB como parâmetro, e invocar esse setter passando uma instância da classe de implementação. Todo isso pra dizer o seguinte, o cliente não está amarrado a um EJB, pois se pode injetar a implementação.
Meu, de boa, o melhor é colocar a interface EJB dentro do managed bean. O framework Seam faz isso e Java EE te estimula a fazer isso, então pra que ficar negando?
injetando? só se for stateless…
Não! O Session Bean Stateless seria implementado criando uma única instância e distribuindo esta para todos os clientes. E o Session Bean Stateful seria implementado criando uma nova instância para cada cliente que a solicita.
O difícil mesmo seria o Message-Driven Bean! Essa nem sei se tem uma alternativa viável.
Não! O Session Bean Stateless seria implementado criando uma única instância e distribuindo esta para todos os clientes. E o Session Bean Stateful seria implementado criando uma nova instância para cada cliente que a solicita.
O difícil mesmo seria o Message-Driven Bean! Essa nem sei se tem uma alternativa viável.
Corrigindo:
Stateless: nao mantem estado entre as reuisições do cliente
Statefull: mantem estado entre as requisições do cliente, é criada uma instancia para cada cliente.
Message Driven Bean implementa JMS e é para processos assincronos.
Pq eu não concordo com suas explicações, pricipalmente com a primeira:
Dizer que o delegate é semelhante ao session, pra começar session é EJB e deleggate não…
Pq eu não concordo com suas explicações, pricipalmente com a primeira:
Dizer que o delegate é semelhante ao session, pra começar session é EJB e deleggate não…
E é um direito seu não concordar com minhas explicações.
Mas lembre-se, não estou trocando um delegate por um session; no EJB 3, estou trocando um delegate por uma interface, o session é quem implementa essa interface, e o cliente não está sabendo da implementação de fato.
Apesar do título dizer que é uma limitação, eu vejo como um avanço o Java EE assumir certas responsabilidades para que o desenvolvedor escreva a aplicação com menos camadas.
Sugiro você ficar olhando para os posts da seção de metodologia do GUJ, sempre tem alguém criticando o desenvolvimento em camadas, você vai aprender que certos “atos de fé” na construção de aplicações web não funcionam direito na prática.