| Autor |
Mensagem |
|
|
Gente, desculpem por reviver o tópico, mas achei um trecho interessante para adicionar.
Pesquisando na internet sobre CRC32, encontrei que, apesar de utilizar todos os bits do arquivo para fazer o cálculo polinomial, é possível alterar os dados sem que o CRC seja modificado. Sendo assim, o melhor mesmo é usar hash pra fazer a tarefa.
Fonte: http://pt.wikipedia.org/wiki/CRC
|
 |
|
|
Diego,
Não tem como ele fazer um load de um null e depois dar um erro de "Transient Value" depois disso. O problema são sessões diferentes. Em algum ponto do seu código você deve testar o valor do objeto para depois fazer um merge. Sacou? Cuidado ao fazer um clone pra resolver isso, pois você pode estar varrendo a poeira pra debaixo do tapete (não digo que está, mas pode estar).
|
|
|
|
|
Beleza, agora posta o conteúdo de "fisicaDao.merge()"
|
|
|
|
Sim, porém veja se vc tá chamando em algum trecho o seu código assim:
Eu já fiz isso para ter certeza que o objeto era o mesmo do banco, mas, como no seu caso, tive um problema quando executava esse método da maneira acima. Por isso digo: posta todos os "merge" que você tiver no seu código, pra gente olhar! 
|
|
|
|
Fala companheiro de batalha!
Seguinte: já passei pelo mesmíssimo problema.
Verifique no seu código se em algum ponto obscuro você inadivertidamente não tá tentando fazer um merge em "idRegimeBens" com o valor null. Aí ele realmente vai retornar um erro.
Caso não seja isso, poste exatamente os trechos de código onde você faz o merge, tanto da propriedade em si como da classe que a contém.
|
|
|
|
Maurício, o projeto pode melhorar; e deve.
O contexto público é um tanto quanto diferente do privado. Como disse antes por todos os colegas, fazer um "novo framework" que faz N coisas já feitas, não é legal.
Mas, como disse antes, uma maneira integradora de aplicações, utilizando outras frameworks, acho agradável e útil.
Patuscadas como essas acontecem com qualquer projeto, principalmente este, que deve ter muita gente envolvida. De vez em quando alguém faz uma caquinha, mas não invalida a idéia de todo um projeto. 
Mas que caquinha essa hein... Hehehhehee 
|
|
|
|
|
Você foi extremamente seco ao detalhar seus problemas. Você pode estar fazendo isso de 1000 maneiras diferentes! Seja um pouquinho mais específico, assim a comunidade te ajuda melhor...
|
|
|
|
Cara, a melhor saída seria você criar classes específicas que sejam especialistas no que fazem. Quer fazer um Jasper? Especialize essa atitude em uma classe. Quer mandar um email com o PDF renderizado pelo Jasper? Especialize isto em outra classe e receba os "bytes" como parâmetro. Assim você aumenta a granularidade e torna o seu código mais testável e reutilizável, ficando assim mais robusto e confiável.
Falow?
|
|
|
|
|
Pô cara, mas, sinto muito, o contexto de transaction dele é fraco (faz um connection manager na mão), utiliza jdbc purão de uma forma que 1000 outros já fizeram. Como te falei: a idéia é boa, não sou contra ela. Mas já olhei o código. Nada foi feito nele além do que outros já fizeram, comprovadamente, melhor. Isso é um desperdício de tempo. Críticas construtivas da comunidade são boas pra mudar o rumo do projeto. Quando todos falam a mesma coisa, é bom pensar que estamos fazendo algo de errado...
|
|
|
|
Pois então. Foi isso que achei esquisito. Primeiro: dá pra ter produtividade fazendo algumas assetivas no projeto e não prendendo o desenvolvedor a um framework. De qualquer forma não sou contra quem faz isso, digo que pode funcionar, mas do jeito que o demoiselle foi projetado ele É intrusivo e, como citado anteriormente, apesar de não ter que aprender muuuitos tópicos para aprendê-lo, talvez ele precise um pouco mais de amadurecimento quanto aos objetivos e áreas de novos frameworks; já extensamente citados neste e em outros tópicos. Acredito que um novo framework tem que nascer sim. Mas não de qualquer forma, pois do jeito que o demoiselle é, já existem mais 10 idênticos, com documentação extensa, exaustivamente testados e com casos de sucesso no mundo todo.
Não sou contra novos frameworks, mas ele tem que ter um "tchans" a mais que os outros... Do jeito que o demoiselle está, o spring dá de 1000. Se fossem fazer um framework de integração: utilizem o spring, ou qq outro que corresponda. Não dá pra construir um carro fazendo as rodas, as portas, o câmbio... Temos que terceirizar. No modelo de negócio atual essa atitude é muito cara pro desenvolvimento do projeto. Tudo bem que é só um desenvolvimento que vai ser reutilizado n vezes, mas voltamos ao círculo vicioso: por que não pegar um pronto, fazer uma frame de integração e institucionalizar uma (várias) arquiteturas neste ambiente? Hum? Hum? Não seria melhor, mais fácil, mais rápido, mais barato...
|
|
|
|
Pcalcado: Me permita dizer, sou um fã de carteirinha do seu Blog, adoro seus posts, são extremamente informativos e úteis, são adendos muito bons à comunidade!
Bem, por algum momento, achei que você estava exagerando, pois acompanho seus posts sobre "frameworks caseiras" falando que elas são "desperdício" e coisa e tal. Discordei de você até o último momento. Foi quando vi o código em questão. Colega, realmente, você NÃO estava exagerando. Se isso não mudar nas outras versões...
Amarrar um contexto de desenvolvimento à alguma coisa, seja ela integradora ou não, mesmo assim significa dependência direta: de pacotes, de chamadas de métodos, e de várias configurações e coisa e tal. Enfim.
A intrusão de código puro, seja ele proveniente de uma jcp (como JSF ou WebBeans) ou seja proveniente de tecnologias "padrão" do mercado (Seam, Guice, etc), dependendo de como ela é estruturada; houve, vai haver, ou (comumente) há problemas. Hoje, frameworks muito desenvolvidas, como o Seam, Spring, já provêem da melhor forma que a tecnologia pode oferecer tudo o que um cidadão como você e eu necessita para sobreviver BEM nesta selva de letrinhas. Falta, realmente, algumas coisas, como utilização de um sistema de segurança de uma maneira adequada (utilizando o que a empresa possui, como ldap), e algumas coisinhas.
Mas não creio que seja de uma forma intrusiva, colocando código dentro de Classes, heranças, etc. seja a melhor saída para resolver todos os problemas.
Talvez, repito: TALVEZ resolvendo o problema de intrusão, o código a ser utilizado no demoiselle fique solto. Não ficar preso a nada pode ser uma estratégia de solução em algumas pontas: como hoje o Spring resolve os problemas de má utilização de código, o demoiselle poderia preencher lacunas não existentes. Assim seria uma brecha para começar a fazer a diferença e aí fazer algo no sentido.
Mas... Sei lá. Mesmo assim é estranho. Será que o pessoal do serpro nunca ouviu falar em JPATemplate? Ou mesmo JdbcTemplate? No aspecto de persistência e web parece um chiuaua com 10 dias de parvovirose querendo morder um pitbull treinado... Porque fazer um JDBCGenericDAO do zero? Se for pra integrar mesmo... Esse JDBCGenericDAO poderia usar um template do Spring em conjunto com dbcp, como um outro colega falou no início. Eles vão girar a manivela umas 10.000x (com muito suor) até chegar à conclusão que a manivela do spring foi girada 10.000.000 de vezes, jogar essa parte fora e adotar o spring?
Talvez isso mereça uma reflexão...
|
|
|
|
Legal saber disso Allessandro, realmente assim fica um pouco melhor. Então falta resolver somente uma coisa no seam (já que não sabia da utilização em outros frameworks de visão): o forte acoplamento com EJB. Não vi ninguém ainda conseguir fazer um lookup de um EJB disponibilizado como componente Seam, ele o amarra deveras. Há alguma maneira de fazer isso?
Bem, se houver... A investida é boa!
|
|
|
|
Exato Elvano, mas só funciona com JSF! O guice pode ser customizado... Eu sou fã do Seam, o acompanho desde a sua concepção, mas acho q ele pecou ao associar-se fortemente ao JSF! 
|
|
|
|
Gostei bastante do post. Também dei uma olhada no Guice, e achei um espetáculo. As mecânicas de configurações do Spring são excelentes, o código foi extremamente bem bolado e produzido, cheios de javadoc e firulas; porém, funcionalmente a arquitetura do guice é mais enxuta e prática em relação ao spring.
Faltava um JCDI da vida pra produzir uma API em comum! Cada um usa agora o de sua preferência. Votei no Guice!
|
|
|
|
Ahh, sim, agora saquei o que você quer fazer.
Bom a má notícia é que não dá pra ser feito: esse parâmetro mexe apenas em tudo o que estiver dentro da tag <properties></properties>, ou seja, geralmente configurações do vendor; OU SEJA (ufa); hibernate, toplink, etc.
Dá pra fazer, vou verificar! 
|
|
|
|
|
|