| Autor |
Mensagem |
|
|
Maurício Linhares wrote:Mas como o Phillip disse, se a transação é só no banco, ela deveria estar dentro dos seus DAOs, não precisa se extender não.
Desse modo, como não cair no anti-pattern "transaction (session) per operation" ?
|
 |
|
|
Se vc estiver usando o tomcat, instale o plugin da sisdeo, que ele cria o contexto direitinho para vc (apontando para a pasta raiz da aplicação WEB dentro do seu worspace).
Neste caso, vc não precisa ficar dando deploy, pois o contexto já aponta para a pasta onde estão suas jsps. Ainda mais, se vc tiver instalado o tomcat 5.5, quando vc recompilar alguma classe, não precisa nem reiniciar o servidor (nem o contexto) a ferramente de hotdeploy do tomcat faz isso pra vc.
|
|
|
|
isso eram informações sigilosas? 
|
|
|
|
Agora que lançaram, o Eclipse ficou mmmmuito mais poderoso! 
Até banco de dados!
De resto pra qm não simpatizava com o Lomboz (eu!), tá com a vida arranjada!
|
|
|
|
|
Algumas classes minhas, precisam acessar arquivos que estão na pasta raiz da minha aplicação WEB. Minhas classes estão no diretório WEB-INF. Pensei em pegar o endereço absoluto do meu projeto no servidor, mas como fazer isto?
|
|
|
|
Ola pessoal,
No lugar onde trabalho, estamos migrando de banco, do SQL Server, pro PostGreSQL.
Td o acesso ao banco e feito por meio de procedures, (Callable Statements). E um pre-requisito da migração, e que os fontes Java, não sejam mechidos.
É aí que aparece o meu maior problema. As procedures do SQL, podem devolver vários campos, já do post não, pois funcionam como funções; assim, qnd é necessário devolver vários campos, eles vem em um "refcursor".
Os CallableStatements do SQL estão +/- assim:
Já os CallableStatements do PostGre, teriam q pegar um refcursor, e não os valores diretos:
Não consegui enxergar nenhuma maneira de não ter que alterar todos os fontes. Talvez sobrescrevendo o metodo executeUpdate();, para que ele faça um tipo de "parse". Mas não creio que seja a maneira mais "elegante".
Alguém tem uma luz?
|
|
|
|
rodrigo_gomes wrote:acho q o banco do brasil tem uma proteção contra esses image loggers...ou pelo menos tenta.
quando vc clica no teclado, imediatamente apos, ele (e tudo que tá sobre ele) some por algus segundos (ou milesimos de segundos...sei lah) , pra evitar que o printScreen "tire a foto" de onde vc clicou
mas o imagelogger não precisa tirar a foto bem qdo vc aperta o botão (seja do teclado real ou do virtual). E o que é pior, só precisa tirar a foto 1 vez (nos sistemas que tenho visto hoje).
|
|
|
|
|
usar Sockets com SOAP, nesse caso seria melhor do que com Corba, ou XML?
|
|
|
|
|
Desculpem-me a ignorância, não achei nd no search, mas o que são os tais POJO's, que td mundo fala?
|
|
|
|
Se o seu problema principal é performance, tenho uma grande impressão de que usar Stored Procedures direto no BD, e só chamar do Java, é muito mais rápido. (ou não, posso estar falando besteira... é um caso pros experts).
repare que ele não disse nada sobre portabilidade, escalabilidade, etc... Não me xinguem!
|
|
|
|
Outro jeito é fazer do objeto que vc quer re-instanciar, sua própria factory.
Complicado?
por exemplo:
bom, pelo menos ***EU*** acho mais elegante que usar reflection...
|
|
|
|
a.llex wrote:2 - Não quero ficar preso ao Windows, portanto qual o banco de dados devo usar para ter meu programa rodando no Windows e Linux no futuro?
Procure aqui pelo fórum por Hibernate, mapeamento objeto relacional, Prevayler, e até quem sabe, PreparedStatement (você que tem q torná-lo portável, "na mão").
|
|
|
|
danieldestro wrote:agora sim!
ainda não!
|
|
|
|