EJB 3.0 e Aplicação Stand Alone

Programação Java
#1

Galera.

Estou tentando fazer umas coisas com EJB, começando a simular um ambiente distribuido, mas estou com um problema.

No NetBeans eu crio uma aplicação EJB e um client java-local…

No Netbeans funciona perfeitamente… hehehe mas quando tento simular um cliente qualquer (Fora da Aplicação EJB) náo consigo…

Eu entro no server (Glassfish) e baixo o ClientStub, adciono ao classPath da aplicação client nova e nada de conseguir chamar as classes…

Alguém pode me dar uma luz ?

O código é :

try {



            Properties props = new Properties();
            props.setProperty("java.naming.factory.initial", "com.sun.enterprise.naming.SerialInitContextFactory");
            props.setProperty("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
            props.setProperty("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");

            
            
            props.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");

            // optional.  Defaults to 3700.  Only needed if target orb port is not 3700.
            props.setProperty("org.omg.CORBA.ORBInitialPort", "3700");





            InitialContext ic = new InitialContext(props);


            PrimeiroEJBRemote p = (PrimeiroEJBRemote) ic.lookup("br.sys.system4.PrimeiroEJBRemote");


            //PrimeiraSessaoBean p = (PrimeiraSessaoBean) ic.lookup("PrimeiraSessaoBean");
            String x = p.primeiroMetodo("Rodrigo");
            System.out.println(x);
        
        
        
        } catch (NamingException ex) {
            Logger.getLogger(Main.class.getName()).log(Level.SEVERE, null, ex);
        }

O problema está na linha

     PrimeiroEJBRemote p = (PrimeiroEJBRemote) ic.lookup("br.sys.system4.PrimeiroEJBRemote");

Ele não acha a referência quando eu tento chamar interface, mesmo mesmo baixando direto do Glassfish o Client Stubs.

Abração e valeu.

#2

[quote=kleins]Galera.

Estou tentando fazer umas coisas com EJB, começando a simular um ambiente distribuido, mas estou com um problema.

No NetBeans eu crio uma aplicação EJB e um client java-local…

No Netbeans funciona perfeitamente… hehehe mas quando tento simular um cliente qualquer (Fora da Aplicação EJB) náo consigo…

Eu entro no server (Glassfish) e baixo o ClientStub, adciono ao classPath da aplicação client nova e nada de conseguir chamar as classes…

[/quote]

Bom… novidades.
Já consegui resolver o problema anterior.
Fiz o deploy no glassfish pela linha de comando e ele gerou o stub…

Agora o problema é que ao chamar o metodo que faz a conexão, ele está ne reclamando o seguinte.

Pesquisando, descobri que tenho que ter no cliente o appserv-rt.jar
http://javacio.us/subscribers/classes/com/sun/logging/LogDomains

Mas mesmo assim náo adiantou…

Alguém tem uma dica ?

abs

#3

Caro kleins,

Como voce consegui resolver este problema, estou com o mesmo problema, e nao sei onde esta o erro, poderia me ajudar

#4

Olá amigo.
Na época como era só teste e acabei não Finalizando.

Abs

#5

Caro Kleins,

Obrigado, como o meu nao é so teste, vou continuar a procurar uma solucao.

Att,

#6

Se puder postar aqui depois ia ser ótimo

Abs

#7

com certeza, quando achar a solucao posto sim

#8

caro kleins,

Resolvi meu problema, coloquei a biblioteca gf-client-module.jar na classpath da aplicacao, e ao executar, deve-se utilizar appclient -client arquivo.jar e nao java -jar como estava fazendo

#9

Boa tarde!!!

Cara, EJB já não é molesa e vocês ainda complicam… rsrs Brincadeira. Todos estamos aqui para aprender.
Bom, por padrão as propriedades que você adicionou são as mesmas do default. Mas menos mau, pois ai aprende-se cada uma.

Sobre a execução existem algumas regras, sobre EJB.

  1. Não é possível ter acesso a bens locais, de fora do container. Logo nenhuma aplicação standalone funcionará tentando recuperar objetos locais. Caso realmente deseje isto deve declarar como Remote, mesmo que esteja usando a mesma JVM;
  2. Caso acesso dentro do container na mesma JVM basta utilizar o nome da classe chamando .class.getName();
  3. Caso acesso de fora do container precisa utilizar JNDI, que possivelmente seja: “java:global/<nome da aplicação>//”

Assim é possível resolver a mesma busca que vcs fizeram sem utilizar appclient do glassfish, pois quando assim o fazem colocam a aplicação cliente dentro do container, funcionando como descrito no item 2.

Até a próxima.

#10

Utilizando o Glassfish 2.x deve-se adicionar ao classpath do cliente os jar: appserv-rt.jar e javaee.jar
Utilizando o Glassfish.3.x deve-se adicionar ao classpath do cliente o jar: gf-client.jar

#11

Caro AGAraujo,

Não entendi muito bem a parte do item 3, por favor poderia explicar novamente, se possivel mostra um exemplo.

att,

#12

Pessoal,

Quais são os jars necessários para o cliente stand alone funcionar?

Meu código é o seguinte:


        Properties jndiProps = new Properties();
        jndiProps.put("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory");
        jndiProps.put("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
        jndiProps.put("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
        jndiProps.setProperty("org.omg.CORBA.ORBInitialHost", "127.0.0.1");
        jndiProps.setProperty("org.omg.CORBA.ORBInitialPort", "3700");
        try {
            InitialContext context = new InitialContext(jndiProps);
            //InitialContext context = new InitialContext();
            String jndiName = "ejb.MySessionRemote#ejb.MySessionRemote";
            Object o = context.lookup(jndiName);
        } catch (NamingException ex) {
            ex.printStackTrace();
        }

Estou recebendo a exceção

Incluí os jars
[list]appserv-rt.jar[/list]
[list]javaee.jar[/list]
[list]jndi-properties.jar [/list]
[list]gf-client.jar[/list]

Já cheguei até a incluir todos os jars da pasta modules e essa exceção continua sendo lançada.

Anteriormente, estava usando o construtor do InitialContext vazio da seguinte forma:


        try {
            InitialContext context = new InitialContext();
            String jndiName = "ejb.MySessionRemote#ejb.MySessionRemote";
            Object o = context.lookup(jndiName);
        } catch (NamingException ex) {
            ex.printStackTrace();
        }

mas era gerada a seguinte exceção:

javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file: java.naming.factory.initial at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:645) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288) at javax.naming.InitialContext.getURLOrDefaultInitCtx(InitialContext.java:325) at javax.naming.InitialContext.lookup(InitialContext.java:392)

#13

Por favor, esqueçam a questão anterior.
Realmente, basta apenas o arquivo gf-client.jar para que funcione.
Meu problema era que eu tinha um projeto com um service locator e eu havia incluído o jar neste projeto, mas meu cliente estava em outro projeto e eu não havia incluído o gf-client.jar neste projeto. Quando fiz isso, funcionou!
Barbeiragem minha!

#14

O que é EJB? Estive procurando um tutorial sobre EJB 3.0, mas não encontro nenhum bom material.
O que é EJB? Para que serve? Como usa-lo?!

#15

Boa tarde Galera, desculpe reviver o tópico, mas estou com exatamente o mesmo problema e não consigo resolver.

Utilizo o Glassfish 3.1.1 e o Netbeans 7.1.

O que ocorre é o seguinte:

Fiz uma aplicação JavaFx de teste, a qual acessa um módulo EJB.

  1. No Netbeans, eu consigo executar a aplicação perfeitamente, necessitando apenas adicionar a biblioteca gf-client.jar OU a biblioteca appserv-rt.jar no projeto. Qualquer uma das duas funciona desde que eu deixe qualquer uma das bibliotecas citadas antes da biblioteca adicionada por padrão javaee-api-6.0.jar na ordem de bibliotecas do projeto Netbeans. (IMPORTANTE)

  2. Para que funcione, ainda no Netbeans, eu NEM sequer preciso indicar a propriedade:

props.setProperty(“java.naming.factory.initial”, “com.sun.enterprise.naming.SerialInitContextFactory”);

Simplesmente, faço o seguinte: InitialContext ic = new InitialContext(); //Isso mesmo sem parâmetros.

E na sequência eu faço o lookup do objeto remoto: EJBRemote p = (EJBRemote) ic.lookup(“EJBRemote”);

E a aplicação funciona, PORÉM SOMENTE DENTRO NO NETBEANS.

  1. Já tentei de inúmeras formas executar essa aplicação fora do Netbeans:

a) Já copiei as libs para o diretório /lib dentro do /dist do projeto;
b) Já tentei executar pelo appclient -client nome_do_projeto.jar;
c) Já tentei pelo Webstart;
d) Já tentei adicionar todas as libs do Glassfish no projeto do netbeans;
e) Já tentei também usando a propriedade props.setProperty(“java.naming.factory.initial”, “com.sun.enterprise.naming.SerialInitContextFactory”);

  1. Considerando que a ideia é executar a aplicação em uma máquina remota, ou seja NÃO é a máquina onde o netbeans ou glassfish está instalado, pergunto: Qual é a maneira correta de instalar a aplicação nessa máquina remota para que acesse corretamente os métodos do módulo EJB? (por favor, somente responda se tiver certeza do que está falando)

  2. Vi que há dentro do diretório bin do glassfish um package-appclient.bat que gera um arquivo appclient.jar no diretório lib do glassfish. Há alguma relação com isso?

  3. As mensagens quando eu executo fora do netbeans variam. Exemplo:

Se eu uso a propriedade props.setProperty(“java.naming.factory.initial”, “com.sun.enterprise.naming.SerialInitContextFactory”), ele diz que não encontra a classe com.sun.enterprise.naming.SerialInitContextFactory (ClassNotFoundException)

Se eu tiro essa propriedade, o sistema diz que eu preciso informar tal propriedade, porém quando eu executo no Netbeans, eu NEM preciso informar que ele funciona.
Achei em um fórum que a partir do Glassfish 3.1 não seria preciso informar a propriedade.

Nas minhas pesquisas, vi que muita gente tem ou teve o mesmo problema, porém não vi nenhuma que resolvesse esse problema.

Quem puder ajudar, agradeço.

Abraço.

#16

Bom…

Pelo que entendi, você está conseguindo fazer pelo NetBeans, logo funciona do lado de fora.
O que precisamos entender agora é qual sua estrutura de execução (diretorios, arquivos, comando de execução… etc.)

Aristofânio

#17

[quote=AGAraujo]Bom…

Pelo que entendi, você está conseguindo fazer pelo NetBeans, logo funciona do lado de fora.
O que precisamos entender agora é qual sua estrutura de execução (diretorios, arquivos, comando de execução… etc.)

Aristofânio[/quote]

Sim. Quanto executo pelo Netbeans funciona, mas infelizmente, até o momento, não funcionou do lado de fora. Não tenho ideia dos comandos que o Netbeans usa para executar a aplicação de modo que ela funcione. O meu chute é que o Netbeans, de alguma forma, carrega todas as libs dependentes.

Como disse, se eu incluir o appserv-rt.jar na biblioteca do projeto, a aplicação já funciona no Netbeans. O jar appserv-rt.jar depende do gf-cliente.jar, o qual depende de outros 30 jars no mínimo.

Acredito que o Netbeans consegue carregar todas as bibliotecas dependentes, o que não acontece quando eu executo a aplicação de fora. Contudo, eu já tentei incluir essas libs no projeto e além de demorar uns 3 minutos para compilar, ainda assim não funciona do lado de fora.

Gostaria que fosse algo mais exato mesmo, tipo: funciona no Netbeans, funciona fora, porém não está sendo assim.

O que eu digo é: Realmente, eu não sei como fazer a aplicação rodar fora. Não encontrei documentação que explique. Encontrei várias pessoas com o mesmo problema na Internet. Por essas razões, peço aos colegas mais experientes com EJB que por favor expliquem-me qual é a maneira correta de se fazer o empacotamento de uma aplicação cliente de um módulo EJB ou informem a documentação de referência.

Desde já, obrigado.

Cleber.

#18

Como eu disse se funciona no NetBeans funciona do lado de fora dele.
Os Bean Locais não podem ser acessados do lado de fora do Container, mas os remotos podem e para isto basta incluir os Jars corretos no class path. Simples assim.
Se está dando errado e está incluindo os Jars corretos então o problema está em outro local. Legal seria que você enviasse o trace do erro, a estrutura de arquivos para execução, etc… informações para que possamos auxiliar…

Mesmo assim dê uma olhada aqui: http://www.youtube.com/watch?v=tetLzF3qwTM

Ari

#19

[quote=AGAraujo]Como eu disse se funciona no NetBeans funciona do lado de fora dele.
Os Bean Locais não podem ser acessados do lado de fora do Container, mas os remotos podem e para isto basta incluir os Jars corretos no class path. Simples assim.
Se está dando errado e está incluindo os Jars corretos então o problema está em outro local. Legal seria que você enviasse o trace do erro, a estrutura de arquivos para execução, etc… informações para que possamos auxiliar…

Mesmo assim dê uma olhada aqui: http://www.youtube.com/watch?v=tetLzF3qwTM

Ari[/quote]

Ari, o link que você enviou, o cara executa somente dentro do Netbeans, portanto, não resolve. Acredito que se alguém conseguir implantar a aplicação em um cliente remoto ou explicar como fazer, resolveria o problema. Quando disse que não funciona fora do Netbeans, não quero dizer que não irá funcionar, digo simplesmente que, especificamente no meu caso, não funciona.

Encontrei algumas coisas novas na net, se eu conseguir fazer funcionar, posto aqui.

Até mais,

Cleber.

#20

[quote=clebertx][quote=AGAraujo]Como eu disse se funciona no NetBeans funciona do lado de fora dele.
Os Bean Locais não podem ser acessados do lado de fora do Container, mas os remotos podem e para isto basta incluir os Jars corretos no class path. Simples assim.
Se está dando errado e está incluindo os Jars corretos então o problema está em outro local. Legal seria que você enviasse o trace do erro, a estrutura de arquivos para execução, etc… informações para que possamos auxiliar…

Mesmo assim dê uma olhada aqui: http://www.youtube.com/watch?v=tetLzF3qwTM

Ari[/quote]

Ari, o link que você enviou, o cara executa somente dentro do Netbeans, portanto, não resolve. Acredito que se alguém conseguir implantar a aplicação em um cliente remoto ou explicar como fazer, resolveria o problema. Quando disse que não funciona fora do Netbeans, não quero dizer que não irá funcionar, digo simplesmente que, especificamente no meu caso, não funciona.

Encontrei algumas coisas novas na net, se eu conseguir fazer funcionar, posto aqui.

Até mais,

Cleber.[/quote]

Consegui fazer funcionar o com um client comum, ou seja, sem ser JavaFx, ainda não tentei com o JavaFx. É fácil d+. Vejam só:

  1. Tem um script package-client na pasta do Glassfish, execute-o;
  2. Ele vai criar um arquivo na pasta lib do glassfish chamado appclient.jar, copie-o para uma pasta;
  3. Descompacte o arquivo appclient.jar nessa pasta;
  4. Esse arquivo tem várias pastas. Dentro da pasta glassfish/bin tem dois scripts: appclient (linux) e appclient.bat (windows). Use o comando appclient -client nome_do_cliente.jar.

Depois vou testar em uma máquina remota e também com a aplicação JavaFx e ver no que dá.

Espero que assim ajude outros colegas que tiveram dificuldade nisso.

Até mais.