Esse problema ja foi solucionado nas versoes 4.2.3 e 4.3.0 para os app servers da série 4.x. A interoperabilidade que o Release Notes se refere, é quanto as versões 4.2.2 e inferiores.
[quote=lavh]Acho que isso é um pouco de egoismo por parte da Jboss. Vai explicar pro seu cliente que ele precisa migrar a versão do Jboss pq
vc quer migrar a sua. [/quote]
Não entendi …
Correções de bugs existem em qualquer produto de software (ainda bem). A versão da série 4.x, homologada para produção com correções de issues e releases é a 4.3.0 (subscription) ou 4.2.3 (community).[/quote]
Então, a gente testou o Jboss 4.2.3 e ele não se comunica com nenhum Jboss abaixo dele usando EJB3. É claro que correções de bugs existem em qlq produto, o problema que eu disse é que eu estou reclamando disso desde a versão 4.2.1 e o problema não é corrigido. Não sei se na 4.3.0 funciona, mas na 4.2.3 com certeza não! Eu não posso migrar um sistema meu pra 4.2.3 senão todos os outros que usam versões anteriores não falam mais com ele. (Isso tudo com EJB 3, com EJB 2 funciona)
lavh, a correção que se encontra no 4.2.3 é existir o serial version. O problema com o 4.2.2/4.2.1 é ele não possuir, o que causa o problema.
Se o seu cliente utiliza a versão com este problema ele deveria ou realmente atualizar a versão ou aplicar os updates daquela versão.
A vantagem do OpenSource se vê neste ponto: vc tem a liberdade de editar o BaseRemoteProxy e adicionar a uid para as versões 4.2.2 ou 4.2.1. A vantagem de se ter suporte tbm se vê neste ponto: seu cliente pode requisitar em tempo de SLA que alguém faça isso por ele (o que na verdade tbm já existe pronto). Ambos podem esperar uma próxima versão com patches acumulativos (nisso não difere o JBoss de qualquer outro produto).
Muito legal a nova versão do JBoss5. Cheio de novas implementações, blablabla… mas a tal injeção de dependência da anotação @EJB ainda não funciona! Enfim… vou partir pro glassfish apenas por cumprir tudo o que se propos a implementar: o mais proximo da especificação!
Essa briga toda é como F1. O JBoss ficou um tempo maior no pit-stop contando que conseguira ter uma autonomia maior e que, com isso, deixara pra traz seus adversarios 8)
Mas o Hammilton é o Glassfish!
[quote=kaiak23]
Tive problemas ao fazer a injeção de dependências de QueueConnectionFactory utilizando o 5.0… No 4.2 funcionava tranquilamente… Agora não mais!!![/quote]
Em servidores parrudos o jb5 demorou 1min17s … já o jb4.2 sobe em apenas 15s no maximo !
Tive problemas com o hibernate do jb5. O relacionamento ManyToMany estava funcionando belezinha no jb4.2. Quanto mudei para o jb5 comecou a apresentar a log:
16:43:34,406 ERROR [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.ConstraintViolationException: could not insert collection rows: [br.com.test.model.Group.ics#11530]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.persister.collection.AbstractCollectionPersister.insertRows(AbstractCollectionPersister.java:1416)
at org.hibernate.action.CollectionUpdateAction.execute(CollectionUpdateAction.java:86)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:170)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1027)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:365)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:137)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:54)
…
Caused by: java.sql.SQLException: ORA-02291: integrity constraint (SYS028382) violated - parent key not found
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:966)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1170)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3339)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3423)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:365)
at org.hibernate.jdbc.NonBatchingBatcher.addToBatch(NonBatchingBatcher.java:46)
at org.hibernate.persister.collection.AbstractCollectionPersister.insertRows(AbstractCollectionPersister.java:1389)
... 70 more[/code]
