Jboss quebra Compatibilidade em caso de Migração?

Cara não deveria em hipotese alguma, agora te pergunto pq sair do 4 e já ir para a 6 , uma vez que a última versão homologada é o 5 ?
O que sei é que o jboss 7 , não dara suporte a sistemas legados, ou seja , o 7 será muito rápido , pois não precisará se preocupar com compatibilidade destes sistemas antigos, algo como EJB2.1 , enfim …
Enfim, pense sempre que quando migramos algo , é necessário fazer inúmeros testes e ver se a versão que você usuará a versão estável do fornecedor , caso contrário , use o novo apenas para testes e aprendizado e ou uso pessoal …abçs …

Lekão

antes de fazer manobras arriscadas desse jeito eu costumo testar em uma máquina virtual…
instale o jboss6 ou 5 em uma maquina virtual de teste e passe suas aplicações pra VM e fique uns 2 ou 3 dias testando…
eu acho (opiniao pessoal) que o esforço e tempo gastos valem a pena nesses casos…

como é essa historia ai do JBoss7? vai ser mais rápido?

Eu fico meio incomodado com essa situação de ter que testar essa migração, porque se o java não quebra compatibilidade, porque o Jboss deveria quebrar?
O meu grande problema é que eu não tenho o source do projeto, so o arquivo deplowado, um .war. Então, se alguma coisa der pau, não tem como entrar e dar manutenção. Então pode ser que eu faça uma rotina de testes de 3 dias, e no ultimo requisito pra teste o servidor falhe. Ai eu vou ter jogado tres dias no lixo.

Thomas Edison fez 1430 tentativas antes de se conseguir fazer a lâmpada elétrica funcionar…
certo dia, quando questionado sobre sua invenção, ele disse: “Além do jeito certo, descobri outras várias formas de não se fazer a lâmpada.”

Sim, pois o grande problema dos servidores e de tantas outras tecnologias , é ter que se preocupar em manter a compatibilidade de sistemas legados… isto faz com que haja um esforço incondicional para se mater esta compatibilidade , você já viu alguma release ser mais rápida que a anterior ? ou você já instalou um novo servidor e já se deparou perguntado…

• A versão anterior parece ser mais rápida que a versão mais atual?
  e isto acontece entre outros motivos , o fato de você ter que manter esta compatibilidade…
  Porém o que tenho visto e a proposta da RH me parece que se vc tem sistemas legados mantenha-los no servidor ou atualize para a versão que de suporte … já o JB7 não dará este suporte ele será composto de coisas novas , ou seja, não precisará manter a compatibilidade , isto fará com que o microkernel dele não fique gastando processamentos desnecessários …entendeu …

Abçs

Lekão

Der Meister:

Thomas Edison fez 1430 tentativas antes de se conseguir fazer a lâmpada elétrica funcionar…
certo dia, quando questionado sobre sua invenção, ele disse: “Além do jeito certo, descobri outras várias formas de não se fazer a lâmpada.”

Traduz ai :?

Jaba
o que eu quis dizer é que mesmo que no último instante dê erro, de uma coisa você irá saber… que a aplicação não roda no JBoss versão x …
isso irá aumentar o seu conhecimento da própria aplicação, sabendo onde roda e onde não roda, então quando alguém do seu trabalho falar "vamos colocar a aplicação no JBoss versão x?"
daí você irá logo dizer “não roda, já testei” é um conhecimento, uma “afinidade”, a mais que você terá do seu sistema, MELHOR ainda é se você ter acesso ao source e saber o porque não roda.

Lekão
putz cara! faz total sentido! não me havia passado pela cabeça que manter compatibilidade com sistemas legados pudesse ser a causa da lentidão de vários servidores.
seguindo essa linha de raciocínio, dá pra estender não só o porque alguns servidores são lentos e pesados… mas dá pra estender esse raciocínio também à aplicações, sistemas, bancos, etc…
vlw pela explicação…

Olá Jaba,

Caso você realmente vá participar de um projeto de migração do JBoss, aconselho a fazer um laboratório/testes, como o Aleksandro citou, justamente por você ter aplicações legadas e por não é possível modificá-las pela ausência do código fonte…

Outra alternativa é se a empresa tem algum tipo de contrato com a Red Hat, pois ai eles podem te auxiliar nesta migração, tendo em vista que entre as versões 4.x e 6.x o kernel do JBoss mudou muito, como por exemplo o MicroContainer, e módulos como o JBoss Messaging, Security, entre outras modificações.

Boa Sorte !!

o JBoss6 quebra a compatibilidade do JBoss4…
eu tenho uma aplicação que uso para fazer testes (um tipo de laboratorio) aqui que roda perfeito no JBoss4.3 quando passei o arquivo WAR pro JBoss6… surpresa…

DEPLOYMENTS MISSING DEPENDENCIES: Deployment "jboss-switchboard:appName=labweb,module=labweb" is missing the following dependencies: Dependency "java:/pg_saturnoDS" (should be in state "Installed", but is actually in state "** NOT FOUND Depends on 'java:/pg_saturnoDS' **")

o estranho é que eu passei o datasource pra pasta do jboss6, que por sinal o WAR e o datasource estão em server/default/deplooy, ou seja, não deveria sentir falta do DS…

resultado:
Há sim quebra de compatiblidade… e olhe que o UNICO framework que esta minha aplicaçao esta usando ,por enquanto, é só o hibernate, imagina se ainda tivesse struts, spring, e outros… o pipoco podia ser bem maior…

Vocês achariam errado ou mal pratica o que eu estou pretendo fazer abaixo?

No meu caso, eu tenho a aplicacao sem o fonte no JBoss4 e uma aplicação qualquer no Cliente.
Como eu tenho que fazer essa integração entre a aplicação no Jboss4 e o cliente, o programa do JBoss4 me força a deployar a integração no proprio JBoss4. Mas e se eu fizesse uma aplicação de integração, por exemplo, com um WebService, e fizesse as outras aplicações necessárias no JBoss5 e conversasse com esse WebService da Aplicação do JBoss4?

Certo, Errado, Mal Pratica?

EU nao faria isso por que a idéia do webservice é fazer plataformas diferentes se entenderem.
se voce tem uma unica plataforma (java, ou C#, ou PHP) entao nao teria porque criar um WS…

e outra, eu tambem nao faria isso para manter a homogeniedade da infra… quanto mais homogênia for a infra melhor para dar manutençao e menor a tendencia de dar erros de compatibilidade …

Der Meister:

EU nao faria isso por que a idéia do webservice é fazer plataformas diferentes se entenderem.
se voce tem uma unica plataforma (java, ou C#, ou PHP) entao nao teria porque criar um WS…

e outra, eu tambem nao faria isso para manter a homogeniedade da infra… quanto mais homogênia for a infra melhor para dar manutençao e menor a tendencia de dar erros de compatibilidade …

Ok, pode ser qualquer comunicação, mais a questão é: Trabalhar com JBoss4 e perder tudo o que o container do JBoss5 te dá, como o EJB3, JPA2, etc, é complicado.
Por isso que eu estou meio que desesperado por uma alternativa.

se voce precisa de tudo o que o container do JBoss5 te dá, como o EJB3, JPA, entao… eu tentaria migrar toda a infra para JBoss5… mas ai seria bom ter o source do projeto para alterar algo que eventualmente tivesse que ser alterado… =/

colega, baixa o JBoss que voce precisa, pega o projeto e coloque no jboss… se funcionar blz… se nao, tente entrar em contato com os desenvolvedor do projeto que voce quer migrar e conversar com eles sobre essa possibilidade de migraçao…

se voce precisa de tudo o que o container do JBoss5 te dá, como o EJB3, JPA, entao… eu tentaria migrar toda a infra para JBoss5… mas ai seria bom ter o source do projeto para alterar algo que eventualmente tivesse que ser alterado… =/

colega, baixa o JBoss que voce precisa, pega o projeto e coloque no jboss… se funcionar blz… se nao, tente entrar em contato com os desenvolvedor do projeto que voce quer migrar e conversar com eles sobre essa possibilidade de migraçao…

EU também acho viável manter os componentes de infraestrutura sempre na mesma versão, para evitar possíveis problemas de compatibilidade…

Acredito que o melhor a ser feito é realmente a criação de um ambiente segregado, para homologação da nova versão da ferramenta…Durante a homologação, você ainda verá pontos a serem melhorados, como configurações adicionais, questões de performance, entre outros, para depois você disponibilizar no ambiente produtivo estes novos componentes de infra/sistema.