Migrando GlassFish v2 para V3

Aqui onde trabalho começamos desenvolvendo sistema web usando o GlassfishV2 com RichFaces e JPA (Hibernate provider).
Há uns meses resolvemos migrar tudo p/ o Glassfish V3 para que fosse possível o uso das novas tecnologias do JEE6 como
CDI, EJB light e JSF2. Nem todas as nossas aplicações estão 100%, mas o que eu posso te dizer com certeza é: não espere
migração sem problemas pois isso não existe. Existem várias incompatibilidades entre o RichFaces 3.x e o JSF2 e uma série
de adaptações precisaram ser feitas e ainda é possível que alguns componentes não funcionem. Ainda é muito mais interessante
que, no case de uma migração agora, vc passe a desenvolver com o PrimeFaces 2.x ao invés do RichFaces que ainda não é
totalmente compatível com o JSF2 (somente apartir da versão 4).

Aconselho que vc instale o glassfishv3 em uma máquina e implante a aplicação para verificar os conflitos e tentar corrigi-los
(qualquer duvida é só postar ai), otimizar o glassfish e só então concluir se realmente vale apena migrar.

vlw era isso que eu estava querendo saber, como alguem ja tenha feito ou passado por essa experiencia. bom voce ter dito vou fazer testes e posto aqui :!:

Eu fiz uma migração de um sistema meu, e só não fiz a migração dos outros porque o Glassfish V3 não tem suporte a cluster ainda (previsão p/ 3.1).

As aplicações que eu migrei usam Vraptor3, então não passei pelos teus problemas quanto ao JSF. O Hibernate funcionou bem, inclusive consegui migrar tudo para JPA2 com Hibernate 3.5 como provider.

A única alteração foi quanto ao service-locator, pois no Glassfish V2 você fazia lookup usando o nome completo da classe, agora o lookup é feito usando a namespace java:app, java:global e java:module. Fora isso nenhuma outra alteração.

Estou é aguardando ansiosamente o suporte a cluster para migrar outras aplicações.

garcia-jj:

Eu fiz uma migração de um sistema meu, e só não fiz a migração dos outros porque o Glassfish V3 não tem suporte a cluster ainda (previsão p/ 3.1).

As aplicações que eu migrei usam Vraptor3, então não passei pelos teus problemas quanto ao JSF. O Hibernate funcionou bem, inclusive consegui migrar tudo para JPA2 com Hibernate 3.5 como provider.

A única alteração foi quanto ao service-locator, pois no Glassfish V2 você fazia lookup usando o nome completo da classe, agora o lookup é feito usando a namespace java:app, java:global e java:module. Fora isso nenhuma outra alteração.

Estou é aguardando ansiosamente o suporte a cluster para migrar outras aplicações.

deixa eu te perguntar como funciona JPA2 com Hibernate 3.5 como provider?

eu uso hibernate com JPA tbm com sessionfactory apontando para um pool de conexão criado dentro do servidor GF2.
usando o configuration.setProperty(“hibernate.connection.datasource”, “pool”);

o que vc acha dessa maneira ou existem melhores? porque caso no V3 não rode dessa minha maneira terei que ir para a sua?!

eu uso hibernate com JPA tbm com sessionfactory apontando para um pool de conexão criado dentro do servidor GF2.
usando o configuration.setProperty(“hibernate.connection.datasource”, “pool”);

Eu não uso esse tipo de coisa porque não é padrão JPA. Ao invés prefiro usar o jta-datasource nas tags do persistence.xml.

<persistence-unit name="default"> <provider>org.hibernate.ejb.HibernatePersistence</provider> <jta-data-source>jdbc/meuDatasource</jta-data-source> </persistence-unit>

Eu fui para esse pool porque antes de eu usar ele o sistema cortava a conexão com o banco direto daí pesquisei e me indicaram fazer pool de conexão! desta forma nunca mais caiu a conexão com o banco.

Mas vou querer então usar esta forma que vc indicou?
será que vai dar muita alteração? outra coisa estou usando jpa1 e hibernate3?

Que comportamento estranho, pois para mim nunca aconteceu isso.

Onde está seu datasource? Está configurado corretamente no domain.xml?

não eu mapeei o hibernate no xml depois eu tenho um hibernate util com as configurações (configuration) para criar a conexão apontnaod para o pool criado dentro do GF apenas isso
//hoje eu uso assim e funciona perfeitamente

private static final SessionFactory sessionFactory;
    private static final ThreadLocal sessionThread = new ThreadLocal();
    private static final ThreadLocal transactionThread = new ThreadLocal();

    static {
        try {
            AnnotationConfiguration configuration = new AnnotationConfiguration();
            configuration.setProperty("hibernate.dialect", "org.hibernate.dialect.SQLServerDialect");
            configuration.setProperty("hibernate.connection.datasource", "Homologacao");//homologação é um pool criado dentro do GFV2
            configuration.setProperty("hibernate.order_updates", "true");
            configuration.setProperty("hibernate.cache.provider_class", "org.hibernate.cache.NoCacheProvider");
            configuration.setProperty("hibernate.show_sql", "false");
            configuration.setProperty("hibernate.format_sql", "true");
            configuration.setProperty("hibernate.current_session_context_class", "thread");

            Scanner.scan(Thread.currentThread().getContextClassLoader(), Collections.EMPTY_SET, Collections.EMPTY_SET, configuration);//essa classe é responsalve por add as anotation class para evitar colocar aqui um monte de add ela varre os pojos e jars da empresa adicionando
            sessionFactory = configuration.buildSessionFactory();
        } catch (Throwable ex) {
            throw new ExceptionInInitializerError(ex);
        }
    }

de configuração do hibernate apenas isso! não tenho problemas, posso ter?

Se você vai usar a session-factory manual então bem faz sentido usar um servidor de aplicações. Se é para usar um appserver, tem que usar as features nele. Se você faz dessa forma como você está fazendo perde-se todo o controle transacional via JTA, propagação de transação, isolation-level, injeção do entity-manager, etc.

Claro que isso depende se você usa todas essas features, mas eu sempre penso que se é para usar um appserver, que seja bem feito.

No seu código você faz scan das classes para ir adicionando ao Hibernate. Se você usar JPA o appserver já lê automaticamente as classes e adiciona na session. Basta você colocar um persistence.xml como eu te coloquei lá encima e você ganha isso de brinde. Além disso o próprio appserver controla as transações, controla o ciclo de vida de cada conexão.

Outro exemplo, você cria um ThreadLocal para ter uma Session do Hibernate para cada acesso. Se você usa um EntityManager você pode injeta-lo dentro do seus Session Beans automagiacamente.

Dentre muitas outras funcionalidades.

pois é realmente bacana! sabe de algum tutorial algo que possa me ajudar à utilizar desta forma que mencionas?

J2EE 6 Tutorial.

obrigado!