Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Novidades do GlassFish 3.1 - Artigo Java Magazine 91
O artigo trata das novidades do servidor de aplicações GlassFish, em sua versão 3.1, lançada recentemente. Em particular, o artigo concentra-se nas funcionalidades de administração de clusters, versionamento de aplicações, etc.
Java Magazine 91
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 91
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 91
Novidades do GlassFish 3.1
Confira as novidades do servidor Java EE da Oracle
Neste artigo, abordamos novidades da recém-lançada versão 3.1 do GlassFish, como clustering, versionamento, escopo de recursos e administração RESTful
De que se trata o artigo:
O artigo trata das novidades do servidor de aplicações GlassFish, em sua versão 3.1, lançada recentemente. Em particular, o artigo concentra-se nas funcionalidades de administração de clusters, versionamento de aplicações, recursos com escopo de aplicação e a API RESTful para administração.
Para que serve:
O GlassFish serve para hospedar aplicações Web e corporativas que sigam o padrão Java EE 6. Em sua versão anterior, 3.0, o servidor já era compatível com a versão 6 do padrão Java para aplicações enterprise, porém as novidades da versão 3.1 fazem do GlassFish um servidor mais robusto e preparado para contextos de produção.
Em que situação o tema é útil:
Descobrir, experimentar e aprender funcionalidades novas de uma ferramenta como o GlassFish é útil para desenvolvedores de aplicações Web e corporativas, além de arquitetos de software ou gerentes de projeto, que devem decidir um servidor a ser utilizado em um determinado projeto de desenvolvimento.
Resumo DevMan:
O GlassFish 3.0 foi desenvolvido como implementação de referência do padrão Java EE 6 e, agora em sua versão 3.1, conta com novas funcionalidades que adicionam características como alta disponibilidade, escalabilidade e tolerância a falhas, que são essenciais para um servidor de produção que hospede aplicações de médio e grande porte. Neste artigo, mostramos como instalar o GlassFish e integrá-lo com as duas IDEs open source mais utilizadas atualmente – Eclipse e NetBeans (Figuras 1 a 4) e, em seguida, detalhamos quatro das novidades da versão 3.1: administração de clusters (Listagens 1 a 3, Figuras 5 a 8), versionamento de aplicações, recursos com escopo de aplicação (Listagens 4 e 5) e a API RESTful de administração (Listagem 6, Figura 9). Para cada funcionalidade, são dadas instruções para que o leitor possa experimentá-las.
Java é uma plataforma de desenvolvimento bastante versátil. Subdividida em várias edições, cada uma possui um propósito específico: Java SE para desenvolvimento de aplicações desktop, Java ME para aplicações móveis, Java Card para desenvolvimento em Smart Cards, etc. Uma destas edições é a Enterprise Edition, ou Java EE, que encontra-se atualmente na versão 6. O Java EE permite a criação de aplicações Web e corporativas. Por “aplicação corporativa” entende-se um software que tem por objetivo resolver um problema de uma empresa ou organização como um todo e, por este motivo, possui requisitos particulares, como escalabilidade, segurança, acessibilidade, dentre outros.
Para executarem, aplicações corporativas devem ser implantadas em servidores de aplicação Java. Um destes servidores é o GlassFish, desenvolvido pela Oracle e disponibilizado em versões gratuita e comercial. O GlassFish nasceu em 2005 como um projeto da Sun a partir do servidor de aplicações comercial já existente na empresa, o Sun Java Application Server 9. Sua versão 1.0 foi desenvolvida para servir de implementação de referência do padrão Java EE 5 (uma implementação completa da especificação construída para demonstrar como ela funciona).
Como o objetivo desta primeira versão era prover uma implementação de referência para o Java EE 5, lhe faltavam funcionalidades que tornassem o GlassFish um servidor interessante para uso em produção, como alta disponibilidade e tolerância a falhas. Assim, este foi o objetivo da versão 2.0 do GlassFish, que adicionou capacidade de clustering (aglomerado de computadores) ao servidor.
Com a publicação, em dezembro de 2009, da nova versão do padrão para aplicações corporativas, o Java EE 6, o GlassFish foi novamente utilizado como implementação de referência e a história se repetiu: o GlassFish 3.0 provia uma implementação completa da especificação Java EE 6, porém sem funcionalidades que o tornassem um servidor de produção escalável e disponível. Somente agora, no final de fevereiro deste ano, que as antigas funcionalidades de clustering além de uma série de outras melhorias foram adicionadas ao servidor com o lançamento do GlassFish 3.1. Algumas destas melhorias – conforme divulgadas pela própria equipe do GlassFish – são:
• Evocação dinâmica de serviços (somente os serviços utilizados são iniciados);
• Melhorias de extensibilidade, tanto no servidor quanto na interface de administração;
• Ciclos de inicialização e implantação (deploy) 29% mais rápidos que na versão 3.0.1;
• Sessão, Stateful Session Beans e EJB Timers são preservados entre re-deploys;
"
Este é um post disponível para assinantes MVP
Confira as novidades do servidor Java EE da Oracle
Neste artigo, abordamos novidades da recém-lançada versão 3.1 do GlassFish, como clustering, versionamento, escopo de recursos e administração RESTful
De que se trata o artigo:
O artigo trata das novidades do servidor de aplicações GlassFish, em sua versão 3.1, lançada recentemente. Em particular, o artigo concentra-se nas funcionalidades de administração de clusters, versionamento de aplicações, recursos com escopo de aplicação e a API RESTful para administração.
Para que serve:
O GlassFish serve para hospedar aplicações Web e corporativas que sigam o padrão Java EE 6. Em sua versão anterior, 3.0, o servidor já era compatível com a versão 6 do padrão Java para aplicações enterprise, porém as novidades da versão 3.1 fazem do GlassFish um servidor mais robusto e preparado para contextos de produção.
Em que situação o tema é útil:
Descobrir, experimentar e aprender funcionalidades novas de uma ferramenta como o GlassFish é útil para desenvolvedores de aplicações Web e corporativas, além de arquitetos de software ou gerentes de projeto, que devem decidir um servidor a ser utilizado em um determinado projeto de desenvolvimento.
Resumo DevMan:
O GlassFish 3.0 foi desenvolvido como implementação de referência do padrão Java EE 6 e, agora em sua versão 3.1, conta com novas funcionalidades que adicionam características como alta disponibilidade, escalabilidade e tolerância a falhas, que são essenciais para um servidor de produção que hospede aplicações de médio e grande porte. Neste artigo, mostramos como instalar o GlassFish e integrá-lo com as duas IDEs open source mais utilizadas atualmente – Eclipse e NetBeans (Figuras 1 a 4) e, em seguida, detalhamos quatro das novidades da versão 3.1: administração de clusters (Listagens 1 a 3, Figuras 5 a 8), versionamento de aplicações, recursos com escopo de aplicação (Listagens 4 e 5) e a API RESTful de administração (Listagem 6, Figura 9). Para cada funcionalidade, são dadas instruções para que o leitor possa experimentá-las.
Java é uma plataforma de desenvolvimento bastante versátil. Subdividida em várias edições, cada uma possui um propósito específico: Java SE para desenvolvimento de aplicações desktop, Java ME para aplicações móveis, Java Card para desenvolvimento em Smart Cards, etc. Uma destas edições é a Enterprise Edition, ou Java EE, que encontra-se atualmente na versão 6. O Java EE permite a criação de aplicações Web e corporativas. Por “aplicação corporativa” entende-se um software que tem por objetivo resolver um problema de uma empresa ou organização como um todo e, por este motivo, possui requisitos particulares, como escalabilidade, segurança, acessibilidade, dentre outros.
Para executarem, aplicações corporativas devem ser implantadas em servidores de aplicação Java. Um destes servidores é o GlassFish, desenvolvido pela Oracle e disponibilizado em versões gratuita e comercial. O GlassFish nasceu em 2005 como um projeto da Sun a partir do servidor de aplicações comercial já existente na empresa, o Sun Java Application Server 9. Sua versão 1.0 foi desenvolvida para servir de implementação de referência do padrão Java EE 5 (uma implementação completa da especificação construída para demonstrar como ela funciona).
Como o objetivo desta primeira versão era prover uma implementação de referência para o Java EE 5, lhe faltavam funcionalidades que tornassem o GlassFish um servidor interessante para uso em produção, como alta disponibilidade e tolerância a falhas. Assim, este foi o objetivo da versão 2.0 do GlassFish, que adicionou capacidade de clustering (aglomerado de computadores) ao servidor.
Com a publicação, em dezembro de 2009, da nova versão do padrão para aplicações corporativas, o Java EE 6, o GlassFish foi novamente utilizado como implementação de referência e a história se repetiu: o GlassFish 3.0 provia uma implementação completa da especificação Java EE 6, porém sem funcionalidades que o tornassem um servidor de produção escalável e disponível. Somente agora, no final de fevereiro deste ano, que as antigas funcionalidades de clustering além de uma série de outras melhorias foram adicionadas ao servidor com o lançamento do GlassFish 3.1. Algumas destas melhorias – conforme divulgadas pela própria equipe do GlassFish – são:
• Evocação dinâmica de serviços (somente os serviços utilizados são iniciados);
• Melhorias de extensibilidade, tanto no servidor quanto na interface de administração;
• Ciclos de inicialização e implantação (deploy) 29% mais rápidos que na versão 3.0.1;
• Sessão, Stateful Session Beans e EJB Timers são preservados entre re-deploys;
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Vítor E. Silva Souza
Professor do Departamento de Informática da Universidade Federal do Espírito Santo. Doutor em Ciência da Computação pela Universidade de Trento, Itália, faz pesquisa na área de Engenharia de Software e Modelagem Conceitual, com experiência em docência em Linguagens de Programação. Desenvolvedor Java...
O que você achou deste post?
20 COMENTÁRIOS
Ythalo Rossy Saldanha Lira
O conceito de cluster é bem complexo devido as diversas nomeclaturas, mas a explicação sobre ficou muito clara e objetivo.
[há +1 ano] -
Responder
Ythalo Rossy Saldanha Lira
Gostaria de informar que ao tentar executar o comando "asadmin create-cluster cluster1" sem iniciar o servidor/dominio "start-domain" obtive o seguinte erro "Remote server does not listen for requests on [localhost:4848]. Is the server up".
[há +1 ano] -
Responder
Vítor Estêvão Silva Souza
Olá Ythalo,
Obrigado pelo comentário. Quanto ao erro, você iniciou o GlassFish antes de executar o comando?
- Vítor Souza
Obrigado pelo comentário. Quanto ao erro, você iniciou o GlassFish antes de executar o comando?
- Vítor Souza
[há +1 ano] -
Responder
Jean Carlos Coelho De Alencar,,
Tenho uma aplicação desktop rodando sobre o glassfish, quando acesso na lan, funciona beleza, mas quando tento acessar fora ele abre a tela de login da aplicação digito usuário e senha, porém ele congela nesta tela. vc saberia me dizer o q pode ser?
[há +1 ano] -
Responder
Vítor Estêvão Silva Souza
Olá Jean Carlos,
Quando você diz que não consegue acessar a aplicação de fora da LAN você está querendo dizer sua própria aplicação ou o console de administração do GlassFish.
No segundo caso, não tenho certeza pois não sou especialista na administração do servidor, mas é possível que haja uma configuração que bloqueie o acesso sem login quando vindo de fora do localhost ou da rede interna.
Se for a sua própria aplicação, não tenho como ajudá-lo. Você deve controlar seu código e verificar as configurações de rede (pode ter algum firewall atrapalhando).
Boa sorte,
- Vítor Souza
Quando você diz que não consegue acessar a aplicação de fora da LAN você está querendo dizer sua própria aplicação ou o console de administração do GlassFish.
No segundo caso, não tenho certeza pois não sou especialista na administração do servidor, mas é possível que haja uma configuração que bloqueie o acesso sem login quando vindo de fora do localhost ou da rede interna.
Se for a sua própria aplicação, não tenho como ajudá-lo. Você deve controlar seu código e verificar as configurações de rede (pode ter algum firewall atrapalhando).
Boa sorte,
- Vítor Souza
[há +1 ano] -
Responder
Jean Carlos Coelho De Alencar,,
É a aplicação! Na realidade, a aplicação eu acesso, abre minha janela de login. Só que quando digito o usuário e senha, a janela congela, como se estivesse esperando uma resposta do servidor!
[há +1 ano] -
Responder
Vítor Estêvão Silva Souza
Jean Carlos,
Verifique então sua rede, pois pode ser algum problema como o que eu citei anteriormente, de firewall.
Outra coisa que você pode fazer é testar um outro servidor de aplicação para determinar se o problema é do GlassFish, mas acho pouco provável. Se a aplicação funciona normalmente quando acessada na rede interna, deveria funcionar igualmente se acessada de fora.
Boa sorte,
- Vítor Souza
Verifique então sua rede, pois pode ser algum problema como o que eu citei anteriormente, de firewall.
Outra coisa que você pode fazer é testar um outro servidor de aplicação para determinar se o problema é do GlassFish, mas acho pouco provável. Se a aplicação funciona normalmente quando acessada na rede interna, deveria funcionar igualmente se acessada de fora.
Boa sorte,
- Vítor Souza
[há +1 ano] -
Responder
Jean Carlos Coelho De Alencar,,
valeu, obrigado!
[há +1 ano] -
Responder
Rodrigo
Boa tarde companheiro, fiz o tutorial como vc explicou no artigo, porém no glassfish 3.1.2, ele instalou as instancias no outro computador porém quando mandei iniciar ele apresentou o seguinte erro:
instance3: Não foi possível iniciar a instância instance3 no nó remotenode (10.148.16.170). O comando falhou no nó remotenode (10.148.16.170): CLI802 A sincronização falhou no diretório config, causada por: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateNotYetValidException: NotBefore: Wed Jun 13 15:52:18 BRT 2012 Falha ao executar o comando start-local-instance. Para concluir esta operação, execute o seguinte comando localmente no host 10.148.16.170 a partir do local de instalação do GlassFish /usr/glassfish3: bin/asadmin start-local-instance --node remotenode --sync normal instance3 instance4: Não foi possível iniciar a instância instance4 no nó remotenode (10.148.16.170). O comando falhou no nó remotenode (10.148.16.170): CLI802 A sincronização falhou no diretório config, causada por: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateNotYetValidException: NotBefore: Wed Jun 13 15:52:18 BRT 2012 Falha ao executar o comando start-local-in .... msg.seeServerLog
Vc tem alguma idéia?
instance3: Não foi possível iniciar a instância instance3 no nó remotenode (10.148.16.170). O comando falhou no nó remotenode (10.148.16.170): CLI802 A sincronização falhou no diretório config, causada por: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateNotYetValidException: NotBefore: Wed Jun 13 15:52:18 BRT 2012 Falha ao executar o comando start-local-instance. Para concluir esta operação, execute o seguinte comando localmente no host 10.148.16.170 a partir do local de instalação do GlassFish /usr/glassfish3: bin/asadmin start-local-instance --node remotenode --sync normal instance3 instance4: Não foi possível iniciar a instância instance4 no nó remotenode (10.148.16.170). O comando falhou no nó remotenode (10.148.16.170): CLI802 A sincronização falhou no diretório config, causada por: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateNotYetValidException: NotBefore: Wed Jun 13 15:52:18 BRT 2012 Falha ao executar o comando start-local-in .... msg.seeServerLog
Vc tem alguma idéia?
[há +1 mês] -
Responder
Wesley Yamazack
Olá Rodrigo entramos em contato com o autor para que ele possa te auxiliar, tudo bem ? Peço que aguarde um pouco até que o mesmo possa retornar o contato.
Um abraço
Um abraço
[há +1 mês] -
Responder
[autor]
Vítor Estêvão Silva Souza
Olá Rodrigo,
Com base no erro:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateNotYetValidException: NotBefore: Wed Jun 13 15:52:18 BRT 2012
Me parece algum problema na configuração da rede. Por algum motivo (talvez relacionado com a configuração da data nos diferentes nós da rede ou com certificados, não sei bem porque não sou especialista na área) as máquinas que participam do cluster não conseguem se comunicar via SSH.
Recomendo buscar ajuda de um especialista em redes neste caso.
Boa sorte,
- Vítor Souza
Com base no erro:
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateNotYetValidException: NotBefore: Wed Jun 13 15:52:18 BRT 2012
Me parece algum problema na configuração da rede. Por algum motivo (talvez relacionado com a configuração da data nos diferentes nós da rede ou com certificados, não sei bem porque não sou especialista na área) as máquinas que participam do cluster não conseguem se comunicar via SSH.
Recomendo buscar ajuda de um especialista em redes neste caso.
Boa sorte,
- Vítor Souza
[há +1 mês] -
Responder
Rodrigo
Ciente, obrigado mesmo assim... uma coisa interessante a ser comentada é que o glassfish da máquina remota tem que estar desativado(não levantado o serviço) se não dá esse erro, quando eu baixei o serviço e mandei levantar as instâncias todas levantaram normalmente e mostraram as aplicações nos nós.
Agora outra dúvida...rsrs eu tenho que configurar todas os recursos jdbc em todos os nós ou ele faz isso sozinho? No remoto a aplicação está lá abre a primeira página ma snão troca informações com o banco de dados...
Agora outra dúvida...rsrs eu tenho que configurar todas os recursos jdbc em todos os nós ou ele faz isso sozinho? No remoto a aplicação está lá abre a primeira página ma snão troca informações com o banco de dados...
[há +1 mês] -
Responder
[autor]
Vítor Estêvão Silva Souza
Se os recursos forem configurados no servidor de forma global (ou seja, não são "Recursos com Escopo de Aplicação", como explica a penúltima seção do artigo), acredito que tenha que ser configurado separadamente em cada nó. Porém talvez isso possa ser feito no Admin Console do servidor de administração do domínio?
Não te dou certeza na resposta porque os exemplos que fiz com cluster não usavam JDBC e não sou especialista no GlassFish (o artigo, como se pode ver, é bem introdutório e mostra as funcionalidades básicas, direcionando o leitor à documentação do servidor caso necessite algo mais aprofundado).
Boa sorte,
- Vítor Souza
Não te dou certeza na resposta porque os exemplos que fiz com cluster não usavam JDBC e não sou especialista no GlassFish (o artigo, como se pode ver, é bem introdutório e mostra as funcionalidades básicas, direcionando o leitor à documentação do servidor caso necessite algo mais aprofundado).
Boa sorte,
- Vítor Souza
[há +1 mês] -
Responder
Rodrigo
Boa Tarde Vitor, desculpe-me mais uma vez pelo questionamento, mas verifiquei a última seção do artigo, a qual fala sobre o registro automático do recurso (jndi) através do glassfish-resources.xml, e não consegui que o glassfish fizesse o deploy da aplicação, se eu faço como anteriormente cadastro o recurso e o pool de conexão e depois o deploy dá certo, porém mesmo configurando da forma que vc descreveu o glassfish não faz o deply e dá o seguinte erro:
Grave: Exception while visiting com/sun/gjc/spi/JdbcObjectsFactory.class of size 3630
java.lang.NullPointerException
at org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
at org.glassfish.hk2.classmodel.reflect.util.JarArchive.onSelectedEntries(JarArchive.java:125)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Grave: Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method
Grave: Exception while preparing the app
Grave: Invalid resource : fobsN__pm
java.lang.RuntimeException: Invalid resource : fobsN__pm
at com.sun.enterprise.connectors.ConnectorRuntime.lookupDataSourceInDAS(ConnectorRuntime.java:540)
at com.sun.enterprise.connectors.ConnectorRuntime.lookupPMResource(ConnectorRuntime.java:469)
at org.glassfish.persistence.common.PersistenceHelper.lookupPMResource(PersistenceHelper.java:63)
at org.glassfish.persistence.jpa.ProviderContainerContractInfoBase.lookupDataSource(ProviderContainerContractInfoBase.java:71)
at org.glassfish.persistence.jpa.PersistenceUnitInfoImpl.<init>(PersistenceUnitInfoImpl.java:108)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:155)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:120)
at org.glassfish.persistence.jpa.JPADeployer$1.visitPUD(JPADeployer.java:224)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:495)
at org.glassfish.persistence.jpa.JPADeployer.createEMFs(JPADeployer.java:233)
at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:168)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:871)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:410)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:214)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:207)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:148)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)
Caused by: com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Invalid resource : fobsN__pm
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl$MyDataSource.validateResource(ConnectorResourceAdminServiceImpl.java:274)
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl$MyDataSource.setResourceInfo(ConnectorResourceAdminServiceImpl.java:255)
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.lookupDataSourceInDAS(ConnectorResourceAdminServiceImpl.java:245)
at com.sun.enterprise.connectors.ConnectorRuntime.lookupDataSourceInDAS(ConnectorRuntime.java:538)
... 63 more
Grave: Exception while visiting com/sun/gjc/spi/JdbcObjectsFactory.class of size 3630
java.lang.NullPointerException
at org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78)
at org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.objectweb.asm.ClassReader.accept(Unknown Source)
at org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363)
at org.glassfish.hk2.classmodel.reflect.util.JarArchive.onSelectedEntries(JarArchive.java:125)
at org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348)
at org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307)
at org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Grave: Exception while invoking class org.glassfish.persistence.jpa.JPADeployer prepare method
Grave: Exception while preparing the app
Grave: Invalid resource : fobsN__pm
java.lang.RuntimeException: Invalid resource : fobsN__pm
at com.sun.enterprise.connectors.ConnectorRuntime.lookupDataSourceInDAS(ConnectorRuntime.java:540)
at com.sun.enterprise.connectors.ConnectorRuntime.lookupPMResource(ConnectorRuntime.java:469)
at org.glassfish.persistence.common.PersistenceHelper.lookupPMResource(PersistenceHelper.java:63)
at org.glassfish.persistence.jpa.ProviderContainerContractInfoBase.lookupDataSource(ProviderContainerContractInfoBase.java:71)
at org.glassfish.persistence.jpa.PersistenceUnitInfoImpl.<init>(PersistenceUnitInfoImpl.java:108)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:155)
at org.glassfish.persistence.jpa.PersistenceUnitLoader.<init>(PersistenceUnitLoader.java:120)
at org.glassfish.persistence.jpa.JPADeployer$1.visitPUD(JPADeployer.java:224)
at org.glassfish.persistence.jpa.JPADeployer$PersistenceUnitDescriptorIterator.iteratePUDs(JPADeployer.java:495)
at org.glassfish.persistence.jpa.JPADeployer.createEMFs(JPADeployer.java:233)
at org.glassfish.persistence.jpa.JPADeployer.prepare(JPADeployer.java:168)
at com.sun.enterprise.v3.server.ApplicationLifecycle.prepareModule(ApplicationLifecycle.java:871)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:410)
at com.sun.enterprise.v3.server.ApplicationLifecycle.deploy(ApplicationLifecycle.java:240)
at org.glassfish.deployment.admin.DeployCommand.execute(DeployCommand.java:389)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:348)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:363)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1085)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$1200(CommandRunnerImpl.java:95)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1291)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1259)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:214)
at org.glassfish.admin.rest.ResourceUtil.runCommand(ResourceUtil.java:207)
at org.glassfish.admin.rest.resources.TemplateListOfResource.createResource(TemplateListOfResource.java:148)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.SubLocatorRule.accept(SubLocatorRule.java:134)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1469)
at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1400)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1349)
at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1339)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer._service(GrizzlyContainer.java:182)
at com.sun.jersey.server.impl.container.grizzly.GrizzlyContainer.service(GrizzlyContainer.java:147)
at org.glassfish.admin.rest.adapter.RestAdapter.service(RestAdapter.java:148)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:179)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:117)
at com.sun.enterprise.v3.services.impl.ContainerMapper$Hk2DispatcherCallable.call(ContainerMapper.java:354)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:195)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:849)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:746)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1045)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:228)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:722)
Caused by: com.sun.appserv.connectors.internal.api.ConnectorRuntimeException: Invalid resource : fobsN__pm
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl$MyDataSource.validateResource(ConnectorResourceAdminServiceImpl.java:274)
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl$MyDataSource.setResourceInfo(ConnectorResourceAdminServiceImpl.java:255)
at com.sun.enterprise.connectors.service.ConnectorResourceAdminServiceImpl.lookupDataSourceInDAS(ConnectorResourceAdminServiceImpl.java:245)
at com.sun.enterprise.connectors.ConnectorRuntime.lookupDataSourceInDAS(ConnectorRuntime.java:538)
... 63 more
[há +1 mês] -
Responder
Diogo Souza
Rodrigo, todas as dependências foram adicionadas à aplicação/servidor?
[há +1 mês] -
Responder
Rodrigo
Bom dia Amigo, consegui colocar ele para funcionar subindo os recursos diretamente no deploy porém ele continua a dar um erro na tela de login como se não conseguisse fazer contato com o banco de dados ou a unidade de persistência não fosse injetada pelo glassfish...
[há +1 mês] -
Responder
[autor]
Vítor Estêvão Silva Souza
Olá Rodrigo,
Qual é o erro apresentado na tela de login?
- Vítor
Qual é o erro apresentado na tela de login?
- Vítor
[há +1 mês] -
Responder
José Marcio Lacerda
é possível utilizar o recurso de versionamento fazendo deploy no painel administrativo ?
[há +1 mês] -
Responder
Diogo Souza.
Está se referindo a automatizar a versão do app/número de deploys feitos?
[há +1 mês] -
Responder
[autor]
Vítor Estêvão Silva Souza
Olá José,
Segundo esta página:
https://blogs.oracle.com/anilam/entry/glassfish_3_1_new_features1
A versão 3.1 do GlassFish possui sim suporte à gerência de múltiplas versões de uma aplicação via painel administrativo (veja item 5 desta página).
- Vítor Souza
Segundo esta página:
https://blogs.oracle.com/anilam/entry/glassfish_3_1_new_features1
A versão 3.1 do GlassFish possui sim suporte à gerência de múltiplas versões de uma aplicação via painel administrativo (veja item 5 desta página).
- Vítor Souza
[há +1 mês] -
Responder
Cursos relacionados
Publicidade
