| Autor |
Mensagem |
|
|
Bom dia,
Estou usando HttpClient para fazer algumas requisições para um aplicativo web desenvolvido aqui na empresa.
Durante essas requisições, às vezes, uma exceção é disparada no servidor indicando uma operação "ilegal".. No nosso tomcat (6.0.29, servidor onde nossa aplicação está rodando) existe uma error-page configurada para tratar esse tipo de exceção e redirecionar para uma página adequada...
Como pretendia testar com json, acabei criando uma servlet para fazer esse controle e decidir se deve redirecionar ou montar um json com a mensagem de erro na resposta... até então parecia isso estava funcionando corretamente nesta implementação...
O meu problema é que o httpclient não recebe o conteúdo json que tentei devolver, mas sim, um erro 500 por conta da exception disparada no servidor..
Minha dúvida: é possível fazer com que o httpclient receba esse retorno (exception tratada) sem usar requisições adicionais?
Estranho que quando tento debugar, parece que o fluxo corre normalmente, a exception é disparada e o bloco que monta a resposta é chamado, mas o cliente só recebe o erro 500...
Alguém tem alguma idéia?
Grato pela atenção,
Éberson
|
 |
|
|
Chegaram a pensar em alguma forma de transmití-lo on line?
|
|
|
|
muehlner wrote:Pelo que sei de Threads se você coloca um synchronized ele funciona igual a uma "chave" que tranca a porta e nenhuma outra Thread pode ser executada enquanto essa não chegar ao fim
exemplo:
espero ter ajuda !
abraços
Se ele estiver instanciando uma nova thread a cada ciclo esse bloco sincronizado não vai servir pra nada... pois as instâncias serão diferentes... e esse "lock" não vai ter nada útil...
Sincronizar um recurso compartilhado poderia ser uma solução, mas depende de como ele construiu o modelo dele...
Vamos aguardar uma resposta para pode indicar algo mais coerente com a sua realidade...
Atenciosamente,
Éberson
|
|
|
|
Olá!
Como assim "eu chamo ela a cada 500 milisegundos"?
Você tem uma thread e fica dando sleep de 500 milisegundos a cada ciclo do seu processo ou cria uma nova thread a cada 500 milisegundos?
Se você estiver usado o sleep não vai ter problema, pois enquanto ela estiver esperando pela entrada não vai chegar no trecho do sleep... agora se estiver criando uma thread nova toda vez, então ela vai ser chamada independente do tempo em que a primeira ficou esperando...
Espero que ajude.
[]s
Éberson
|
|
|
|
FernandoFranzini wrote:
Se a abstração do Repository é a mesma do DAO, qual a diferença em usar um ou outro modelo?
Veja o livro do DDD do Eric Vans falando sobre o padrão repositório na pagina 147 e compare com o JEE patters - http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html.
Vc vera q semanticamente falando não existe diferença nenhuma.....o Eric Vans apenas trocou o nome para gerar uma "grupo de padrões" voltados para a aplicação sistemática DDD.
Vc vc até pode fazer assim, mas vai duplicar uma abstração desnecessária...adicionando uma camada polimorfica sem sentido arquitetural...
Vc pode tentar me convencer ao contrario...caso vc justifique ter 2 abstrações polimórficas....e ai?
Descreva em que caso vc haverá diferentes implementações de Repositorios e DAO's.....
Hum... acho que entendi...
No que andei lendo o Repository existe como um objeto além do DAO apenas para poder existir dentro do "pacote do domínio" e atender ao DDD... ao delegar as tarefas para o dao... ele não passa de um dao mascarado que pode existir num pacote separado dos daos propriamente dito... vendo assim, consigo entender e concluir que são a mesma coisa...
hum... não sei dizer quando são necessárias duas implementações distintas (DAO e Repository) nem se são realmente necessárias... vou continuar estudando....
valew
|
|
|
|
FernandoFranzini wrote:
Acredito que não ficaria redundante... estive lendo sobre o assunto recentemente e entendi que deveriam existir ambos Repository e DAO, já que o Repository não deveria se envolver em questões de infra estrutura...
A questão é q não envolve....
1) Faz 1 interface RepositoryCliente com as operações.
2) Gere filosofias diferentes de respositorios polimorficamente..tipo:
- RepositoryClienteOracleImp
- RepositoryClienteMySqlImp
- RepositoryClienteWebServiceImp
- RepositoryClienteLDAPImp
- Etc....
Não existe necessidade de colocar outra abstração de DAO dentro...é so deixar o polimorfismo fazer o trabalho dele...
Vou insistir para poder entender...
Se a abstração do Repository é a mesma do DAO, qual a diferença em usar um ou outro modelo?
Implementando dessa forma eu não vou estar envolvendo o meu Repository com a infra? Como que o RepositoryClienteMySqlImp, por exemplo, faria uma inserção sem usar dao ou outro mecanismo que trabalhe diretamente com a infra? Ele enviaria um comando sql diretamente (caso estivessemos usando jdbc puro) para o banco?
Acabei encontrando esse diagrama sobre esse "padrão" (hum... nunca usei anexo aqui.. espero ter enviado corretamente).
E acabei entendendo que o principal motivo para existência do Repository era a tradução de consultas, para que consultas mais complexas pudessem ser elaboradas de forma "mais simples".
Fiquei procurando e encontrei os links dos quais falei, seguem:
http://sergiotaborda.wordpress.com/desenvolvimento-de-software/java/patterns/repository/
http://blog.caelum.com.br/repository-seu-modelo-mais-orientado-a-objeto/
http://manifesto.blog.br/1.5/Blog/Programa%C3%A7%C3%A3o/repository-pattern.html
Desculpe se estiver falando bobagem, mas acho que Repository e DAO tem propósitos um pouco diferentes e podem coexistir sem problemas, e, mais do que isso, quero entender para poder aplicá-lo corretamente em alguns testes que pretendo fazer aqui...
|
|
|
|
Caso eu resolvesse usar o repository (Isso é so suposição para meu entendimento, não faz parte do meu trabalho não, nem sou arquiteto), eu teria então VIEW --> BUSINESS--> REPOSITORY --> DAO.
Acredito que seria algo mais ou menos assim...
O repositóry não criaria um passo redundante, levando em conta que ja tenho uma camada tratando negócio ? Posso crer que o repository dispensa outras camadas de negócio ? Ou ele seria complemento ao negócio ?
Acredito que não ficaria redundante... estive lendo sobre o assunto recentemente e entendi que deveriam existir ambos Repository e DAO, já que o Repository não deveria se envolver em questões de infra estrutura...
No material que estive lendo (estou sem os links aqui, mas um foi no blog do sergio taborda e outro no blog da caelum) me pareceu uma forma de oferecer aos beans de modelo um pouco mais de responsabilidade...
Os Repository's ficariam no mesmo pacote dos beans e seriam uma espécie de extensão do modelo... Pelo que entendi, esses Repository's apenas encapsulariam as chamadas aos daos e fariam a tradução das consultas de alto nível (sem uso de sql ou outro comando de infra) para que os daos pudessem executa-las e isolariam ainda mais a camada de infra....
Pelo que pude entender, cada bean de modelo poderia ter uma instancia desse Repository para que pudesse oferecer consultas de forma mais simples dando a ideia de que as classes de negocios trabalham com uma lista de objetos em memória o inves de algo no banco de dados... e os objetos com a regra de negocio iriam trabalhar com eles ao inves de usar os daos diretamente...
não sei se falei besteira... se tiver me corrijam...
|
|
|
|
Bom dia,
Estou me aventurando num aplicativo que rode no GAE basedo no JSF 2.0, prime-faces e twig-persist...
Tive vários problemas para rodar o JSF (se fosse começar hoje não usaria), mas está rodando até bem.
O meu problema agora é com o Twig ou o datastore (ainda não sei dizer).
Tenho duas classes (vou remover os getters e setters para nao ocupar muito espaço):
e
Para facilitar meus testes criei classes para povoar minha base de dados:
e
Ao testar no ambiente de desenvolvimento, o primeiro produtor de dados executa normal.. ao executar o segundo ele não encontra todos os itens adicionados pelo primeiro. Ao debugar notei que se ficar inspecionando o findAll várias vezes ele vai carregando mais registros até chegar a quantidade correta. Imaginei que isso fosse um delay para disponibilizar os dados.
Será que é isso mesmo? Se sim, como faço para evitar os problemas que posso ter com esse atraso? Será um problema com o Twig? Não cheguei a testar com o Objectfy (devo fazer isso entre hoje e amanhã) será que terei o mesmo problema?
Alguém pode me ajudar, por favor?
Grato pela atenção,
Éberson
|
|
|
|
Olá pessoal,
Estou tendo problemas para usar beans de sessão no GAE..
Implementei um bean simples para checar o usuário e senha de um usuário baseado nos dados gravados no datastore.
Essa implementação funciona normalmente no ambiente de desenvolvimento (GAE 1.5.1), mas não funciona no ambiente de produção.
Coloquei alguns logs e notei que meu bean buscou os dados no datastore e os encontrou.
Após isso eu redireciono a aplicação para a página principal onde existe um componente que será renderizado somente se houver dados nesse bean de sessão. A página não renderizou como o esperado no ambiente de produção, mas funcionou normalmente no ambiente de desenvolvimento.
Alguém já passou por isso? Se sim como resolveu?
Alguém sabe por que a aplicação se comporta diferente no ambiente de desenvolvimento e produção?
Grato pela atenção
Éberson
|
|
|
|
Parabéns pela iniciativa!!
Esse framework parece bem legal e será de grande ajuda.
Vou começar a testar e vou relatando minhas experiências.
[]s
|
|
|
|
Olá,
Onde está essa grade?
Acabei de olhar no site: http://voit360.com.br/loja/product.php?id_product=12 e encontrei uma grade diferente.. será que estou olhando no lugar errado?
[]
Éberson
|
|
|
|
Bom dia,
Depois de muito pesquisar e fuçar... acabei invertendo o processo padrão:
1 - Descobrir quem será o próximo a receber o foco
2 - Executar a validação de quem estava com o foco
3 - Mandar o foco para o componente descoberto no item 1
para:
1 - Executar a validação de quem estava com o foco
2 - Descobrir quem será o próximo a receber o foco
3 - Mandar o foco para o componente descoberto no item anterior..
Não sei se é uma boa solução... mas resolve o meu problema...
Fico grato pela atenção que tiveram com meu problema...
[]s
|
|
|
|
O problema é que não sou eu quem chama a validação nem a mudança de foco. Eu não mexi nesses eventos... Eu apenas escrevi um InputVerifier e coloquei no componente e escrevi uma lógica para identificar que é o próximo a receber o foco... quando esses meus dois componentes serão invocados não está sob o meu controle... é o java quem está controlando isso...
|
|
|
|
Bom dia,
Li o seu tópico mas o problema aqui é diferente.
Envolve habilitar/desabilitar determinados campos juntamente com o processo de foco.
O que eu preciso:
- Tenho uma tela T.
- Dentro dessa tela eu tenho três campos: A, B e C.
- Os campos A e C estão sempre habilitados.
- O campo B fica desabilitado e só habilita quando o conteúdo de A for válido.
- O conteúdo de A será valido de acordo com uma regra que coloquei dentro de um InputVerifier. Após validar o campo A, eu disparo um listener (que acabei criando aqui) que permite atualizar o estado de todos os componentes que dependem do campo A. Assim o campo B fica sabendo que o conteúdo do campo A é válido e habilita para edição.
- O foco deve começar no campo A. Ao sair desse campo o foco deve ir para o campo B se estiver habilitado ou para o campo C caso o campo B estiver desabilitado.
O fluxo que verifiquei ocorre mais ou menos assim:
- Campo A vai perder o foco
- A FocusTranversalPolicy deve indicar qual é o próximo componente que receberá o foco
- O componente eleito sofrerá um requestFocus
- A validação do campo A será executada. Se for executada com sucesso o foco vai para o campo eleito, do contrário fica no campo com conteúdo considerado inválido.
Meu problema é que ao invocar a FocusTransversalPolicy o campo B ainda está desabilitado, pois a validação do campo A ainda não foi executada. Logo, a minha policy indica que o campo C deve receber o foco... daí o campo C recebe um requestFocus que dispara a validação do campo A. O campo A é validado e notifica os ouvintes, habilitando o campo B, mas o foco já foi enviado para o campo C.
Entende o meu problema?
Espero ter sido claro,
[]s
Éberson
|
|
|
|
Bom dia,
Andei fazendo umas pesquisas e cheguei a duas possíveis soluções:
- Invocar o processo de validação dentro do transferFocus dos meus componentes, assim poderei "adiantar" o processo e garantir que o componente eleito pela minha FocusTransversalPolicy é o componente que pode receber o foco. Acho que essa funciona, mas não sei se é seguro/recomendado modificar esse comportamento.
- Ao invés de tornar meu campo desabilitado vou tentar torná-lo não editável. Não sei se isso vai resolver, vou testar e ver o que acontece. Não sei se vai funcionar, pois ao torná-lo não editável terei que adicionar essa regra à minha política de foco e pode ser que o mesmo problema ocorra novamente.
Se alguém puder me ajudar...
[]s
Éberson
|
|
|
|