Boa Tarde a todos,
Estou com uma dúvida referente a criação de classes e beans no JSF 2.0.
Em primeiro lugar, gostaria de saber se é necessário gerar o SerialVersionUID manualmente para todas as classes que eu criar, ou se, simplesmente implementando a Interface Serializable o JSF ja se encarrega de gerar este número para mim.
Obrigado.
Vc realmente precisa desse número?
Então, pelo que pesquisei esse número é gerado com base nos atributos da classe, e serve para identifica-la, o problema é que no meu projeto acusa um erro dizendo que tal classe não implementa a interface Serializable, porém, assim que atribuo a interface, aparece outro erro :
error: local class incompatible: stream classdec serialversionUID= 23611651161165116511L , local class serialversionUID = 16518131351616511
eu faço assin
@ViewScoped
@ManagedBean(name = "assuntoController")
public class AssuntoController extends CRUDGenerico<Assunto> implements Serializable {
private static final long serialVersionUID = 1L;
pois como voce falou se naum implementar Serializable da erro, e assim funciona tudo certinho…
Eu faço o implements Serializable em meus MBs mas nem declaro esse cara.
Nunca tivesse esse erro… O.o
Esse problema é comum de classes que implementam Serializable sem definir o SerialVersionUID.
A nova classe compilada gerou um número diferente do que você tinha antes, agora, o servidor está se batendo entre a “nova” classe e a que você tinha.
Fazer o undeploy do projeto no servidor, e um clean antes de mandar rodar novamente deve ser o suficiente pra ele voltar a funcionar.
Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…
Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?
[quote=well.nunes]Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…
Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?[/quote]Segurança?
Primeiro você precisa entender para que ele serve e depois você vê se para sua aplicação é ideal ou não declará-lo.
[quote=well.nunes]Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…
Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?[/quote]
Não por segurança, mas por lógica, setar o valor de SerialVersionUID é uma boa prática, pois em casos onde a serialização não é temporária voce pode ter sérios problemas, portanto, entenda a serialização e entenda qual valor atribuir a esta propriedade
[quote=cleciusjm][quote=well.nunes]Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…
Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?[/quote]
Não por segurança, mas por lógica, setar o valor de SerialVersionUID é uma boa prática, pois em casos onde a serialização não é temporária voce pode ter sérios problemas, portanto, entenda a serialização e entenda qual valor atribuir a esta propriedade[/quote]Você teria uma referência disso?
Nunca vi ninguém falando sobre ele como boa prática e gostaria de ver mais sobre isso. =D
[quote=Hebert Coelho][quote=cleciusjm][quote=well.nunes]Obrigado, era realmente esse o problema, fiz apenas o Redeploy no Servidor e rodou normalmente sem erros…
Mas apenas para finalizar, por segurança é melhor colocar o SerialVersionUID manualmente ?[/quote]
Não por segurança, mas por lógica, setar o valor de SerialVersionUID é uma boa prática, pois em casos onde a serialização não é temporária voce pode ter sérios problemas, portanto, entenda a serialização e entenda qual valor atribuir a esta propriedade[/quote]Você teria uma referência disso?
Nunca vi ninguém falando sobre ele como boa prática e gostaria de ver mais sobre isso. =D[/quote]
Não possuo nenhuma referencia no momento, porém sempre interpretei como uma boa prática porque versionamento declarativo da classe é muito importante em ambientes onde a serialização é muito utilizada. Isso lhe confere o poder de dizer quando uma determinada versão de classe passa a não ser mais retrocompatível com as outra classes do ecossitema.
No caso o exemplo que eu tenho é um sistema de transações financeiras distribuido que trabalha com EJB, e isso permite que ao executar o deploy de um plugin deste sistema eu já tenha a validação se o modelo de DTO existente nesse plugin é compatível com a versão do core que está em runtime. Isso evita muitos erros difíceis de detectar.
[quote=cleciusjm]Não possuo nenhuma referencia no momento, porém sempre interpretei como uma boa prática porque versionamento declarativo da classe é muito importante em ambientes onde a serialização é muito utilizada. Isso lhe confere o poder de dizer quando uma determinada versão de classe passa a não ser mais retrocompatível com as outra classes do ecossitema.
No caso o exemplo que eu tenho é um sistema de transações financeiras distribuido que trabalha com EJB, e isso permite que ao executar o deploy de um plugin deste sistema eu já tenha a validação se o modelo de DTO existente nesse plugin é compatível com a versão do core que está em runtime. Isso evita muitos erros difíceis de detectar.[/quote]Sempre achei esse tipo de erro bem claro e que deveria ser aplicado apenas sob necessidade. [=
Valeu. [=
Obrigado a todos pela boa vontade em responder a questão, realmente foi muito esclarecedor, irei estudar mais sobre o assunto…
Boa tarde e obrigado…
Bom, esse ID serve pra dizer se uma versão da classe é compatível com a outra. O que isso quer dizer?
Vamos supor que você tem uma classe Pessoa com um atributo nome, que implementa java.io.Serializable. Essa classe vai ter sim um id associado a ela, quer você defina ou não, se tem dúvidas, é só usar a ferramenta serialver que vem na JDK.
Se um dia você quiser adicionar um atributo sobrenome à mesma classe, você precisa decidir se quer que a versão seja atualizada pra funcionar, ou se os clientes que tem a versão só com o nome ainda podem utilizar a classe sem problemas.
Se você quer que seja atualizado é simples, basta não definir serialVersionUID nenhum, e durante a desserialização, será lançada uma InvalidClassException
Agora se quer que a versão nova seja compatível com a antiga, basta definir o mesmo serialVersionUID para as 2 e pronto.
Agora quanto a ser boa prática ou não, concordo com o Hébert. Ainda mais que se você ficar atualizando o serialVersion cada vez que mexe na classe, está tendo o mesmo resultado que teria se não definisse nada
[quote=Rodrigo Sasaki]
Agora quanto a ser boa prática ou não, concordo com o Hébert. Ainda mais que se você ficar atualizando o serialVersion cada vez que mexe na classe, está tendo o mesmo resultado que teria se não definisse nada[/quote]
Realmente, é no minimo ilógico redefinir o UID a cada alteração, por isto que é importante definir ele sempre em um ambiente onde serialização é utilizada, pois dessa forma voce pode declarativamente determinar que uma versão não é mais retrocompatível, evitando que eventuais pequenas mudanças não geram essa incompatibilidade com o resto do ecossistema.
[quote=cleciusjm][quote=Rodrigo Sasaki]
Agora quanto a ser boa prática ou não, concordo com o Hébert. Ainda mais que se você ficar atualizando o serialVersion cada vez que mexe na classe, está tendo o mesmo resultado que teria se não definisse nada[/quote]
Realmente, é no minimo ilógico redefinir o UID a cada alteração, por isto que é importante definir ele sempre em um ambiente onde serialização é utilizada, pois dessa forma voce pode declarativamente determinar que uma versão não é mais retrocompatível, evitando que eventuais pequenas mudanças não geram essa incompatibilidade com o resto do ecossistema.[/quote]Pq ilógico?
Já li livro falando sobre isso… se não me engano foi o release it que fala sobre vantagem e desvantagem.