| Autor |
Mensagem |
|
|
Bom dia
Esses valores que você colocou provavelmente não deve ser em São Paulo, porque se for esta muito abaixo da média salarial, faça uma pesquisa em algumas vagas em sites como Apinfo e netcarreiras e vai ver que a média de salários para Programador Sênior esta bem acima dessa que você disse.
Falou.
|
 |
|
|
Boa tarde
Então, consegui fazer a aplicação funcionar no JBoss 5.1, para isso foi necessário algumas mudanças na aplicação e principalmente na parte das libs dos frameworks.
O Hibernate que utilizei foi o 4.1.2, nesse foi necessário a remoção dos jars do log4J e xml-apis, pois estes já estão no JBoss, e caso você os adicione no seu WEB-INF/lib o JBoss lança uma ClassCastException.
No caso do VRaptor, estou utilizando a versão 3.4.1, neste só foi necessário declarar o filtro no web.xml, isso foi necessário porque sem a declaração explicita o contexto não era iniciado.
O Spring utilizado foi o 3.1.1, nesse a configuração é basicamente no applicationContext, porque para a criação do EntityManagerFactory é necessário apontar explicitamente o local do seu persistence.xml, segue o código do applicationContext.xml:
Para que o Spring possa gerenciar a contexto de persistência foi necessário usar tag persistenceXmlLocation para localizar o persistence.xml, usando a tag persistenceUnitName o Spring não conseguia localizar as entidades e criar o EntityManagerFactory.
Na configuração da JPA 2 a mudança necessária foi com relação a nomenclatura do persistence.xml, no JBoss 5.1 tiver que renomear para um outro nome, no caso modifiquei para spring-persistence.xml, o arquivo ficou da seguinte forma:
Valeu.
|
 |
|
|
Boa tarde
Então Paulo, realmente estou achando que o problema esteja ligado a incompatibilidade do conteiner com a JPA 2, nos tutoriais que segui e informações que achei na net, uns falam que conseguiram rodar fazendo algumas mudanças em uns arquivos de configuração do JBoss, e outros dizem que a mesma mudança não resolveu o problema, vou fazer um teste no JBoss 6 para ver se nele a aplicação com JPA 2 funciona normal.
Valeu.
|
 |
|
|
Boa Tarde
Então, sim a classe esta mapeada certo, o problema é que o Spring não esta conseguindo subir o contexto de persistência por algum motivo, fiz alguns outros testes com JUnit e funcionou normal, e também realizei o deploy do mesmo .war no Tomcat 7 e funcionou normal.
Valeu.
|
 |
|
|
Boa tarde
Pessoal, nos estamos desenvolvendo um software utilizando JPA 2 (Hibernate 4 como provider) e Spring 3, até o momento esse sistema iria rodar em um conteiner que segue a especificação JEE 6, onde JPA 2 esta incluída, agora há a necessidade desse mesmo software rodar também em um conteiner JEE 5, que no caso será o JBoss 5.1.
Realizei vários testes com todos os frameworks que utilizamos no software, assim seria possível verificar sua compatibilidade com o conteiner mais antigo, VRaptor 3.4, Hibernate 4 e Spring 3, consegui fazer funcionar, bastando apenas trocar alguns JAR'S que no JBoss estavam causando erros de incompatibilidade que são eles SL4J, LOG4J e o XML-APIS.
Para conseguir fazer funcionar a JPA 2 segui alguns tutorias de pessoas que estavam com o mesmo problema, segue os links:
http://java.dzone.com/articles/ejb3-jpa-error-when-migrating
https://community.jboss.org/thread/159628?_sscc=t
Ao realizar o deploy do .war no JBoss 5.1 é gerado a seguinte exception:
Mas mesmo com essa exception sendo gerada, a aplicação é iniciada normalmente, mas o EntityManagerFactory não é criado, assim ao solicitar um recurso que realiza uma chamada no banco de dados, outra exception é gerada:
Gostaria de saber se alguém sabe oque pode estar causando tais erros, e se no caso do JBoss 5.1 com JPA 2 são necessárias outras configurações ?
Obrigado.
|
 |
|
|
As minhas informações sobre as certificações que fiz na época da Prometric constam no site normalmente, meu cadastro foi atualizado na época que eles mandaram o aviso pedindo para realizar os procedimentos de alteração de Prometric para PersonVUE.
Até mais.
|
 |
|
|
Então Zenas, coloca a exception que esta sendo gerada assim fica mais fácil de ajudar, só para adiantar, aqui tem exemplos de como utilizar o método createSQLQuery http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/querysql.html dê uma olhada nos exemplos e verifique se o seu código esta de acordo.
Falou.
|
 |
|
|
Dê uma olhada nesse post aqui do GUJ http://www.guj.com.br/java/116296-finalizar-conexoes---trabalhando-com-hibernatejpac3p0mysql acho que pode te ajudar com os parâmetros do C3P0.
Falou.
|
 |
|
|
Boa tarde
Conheço esses, recomendo:
http://www.lcm.com.br/versao_nova/index.php?Escolha=20&Livro=L00783
http://www.lcm.com.br/versao_nova/index.php?Escolha=20&Livro=L00961
http://www.submarino.com.br/produto/1/21400621/spring+em+acao
Fora a própria documentação, que é muito boa.
Falou.
|
 |
|
|
Boa tarde
Então realmente para as @NamedQuery o hibernate carrega todas as querys em memória, habilitei o log e pude reparar esse comportamento.
Valeu.
|
 |
|
|
Boa noite
Estou tendo que analisar o cache dos SQL gerados pelo JPA/Hibernate, estou trabalhando em um sistema onde a maioria das consultas são geradas através do createQuery ou createNamedQuery da JPA (EntityManager).
Analisando o log de execução do hibernate ele faz os seguintes procedimentos:
Ao iniciar o EntityManagerFactory ele analisa todas as Entitys que possuem as anotações de NamedQuery e cria os respectivos SQL;
Ao chamar os métodos que trabalham com o método createQuery, aparentemente ele faz o mesmo processo da NamedQuery, só que ao invés de gerar o SQL na criação do EntityManagerFactory, ele o faz assim que o método é chamado pela 1º vez dentro do sistema.
Após os processos acima, analisando o log de execução, ao chamar algum método que execute um NamedQuery ou invoca um createQuery, o Hibernate não analisa novamente a Entity e já executa o SQL, aparentemente ele já tem o mesmo carregado em mémoria.
Minha dúvida é se o Hibernate já faz esse tipo de cache de SQL por padrão (seja por HQL em métodos ou por NamedQuery), ou é necessário alguma configuração extra ?
Obrigado.
|
 |
|
|
Boa tarde
Então Bruno, como o VRaptor é baseado em Spring você pode realizar a injeção através do construtor ou atributo, para resolver seu problema eu tentaria através do atributo e com a anotação @Autowired, ficaria assim:
Falou.
|
 |
|
|
Solucionei o problema, acontecia que o Locale não esta sendo setado na chamada do método, então o arquivo .properties não era carregado e a chave correspondente não era encontrada.
Passos realizados para solução do problema:
1º) No web.xml adicionei os parâmetros de contexto para carregar os .properties e inicializar o idioma default como PT:
2º) Para setar o idioma e carregar o .properties desejado, no controller fiz um método com a seguinte lógica:
3º) Para as mensagens estáticas do sistema utilizei a biblioteca fmt da JSTL para recuperar as chaves do .properties, e dentro dos controllers utilizei a interface Localization do VRaptor.
Valeu.
|
 |
|
|
Boa Noite
Estou desenvolvendo uma aplicação onde estou usando a JSTL para gerenciar a parte de internacionalização, nas páginas jsp utilizando a tag fmt da JSTL a internacionalização esta funcionando normalmente, agora no sistema apareceu a necessidade de alguns textos que não podem ser exibidos através da fmt sejam internacionalizados, pois são oriundos de requisições ajax e retornados através de objetos JSON.
Estou setando a escolha do idioma da seguinte forma:
Tentei utilizar a Interface do VRaptor Localization com o método getMessage(), para recuperar a mensagem antes do processo de serialização em JSON, mas não estou conseguindo, o método sempre retorna ????chave.properties???, que de acordo com o javadoc significa que não encontrou nada para aquela chave de acesso.
Alguém saberia como corrigir tal problema ?
Obrigado.
|
 |
|
|
Tambem gostei muito das novidades.
Não obstante, ainda estou no aguardo de ver uma empresa (ao menos aqui em SP) utilizando as especificações do EE 6...
Tem empresas que estão investindo sim, eu pelo menos conheço algumas, acredito que a principal dificuldade das empresas em iniciar nas novas especificações do JEE 6, é devido a adoção de novos conteiners que seguem a especificação (pelo menos é oque ando vendo por ai).
Até mais.
|
 |
|
|
|
|