Últimas notícias do evento

Segurança no HTTP GET Request

Postado em Atualizado em

Veja este artigo que apresenta uma solução flexível e transparente que acrescenta uma camada de segurança sobres os valores trafegados no HttpRequest feitos em cima de pedido HTTP GET. É implementando um modelo de criptografia, impedindo que o usuário no navegador visualize ou interaja diretamente sobres os parâmetros enviados. A idéia da mecânica é bem interessante e vale a pena conferir, uma vez que pode acontecer casos em que se deseje usar um simples HTTP GET para enviar valores para o servidor sem que o usuário final tenha visualização disso.

Swing com MIDP 2.0

Postado em Atualizado em

Escrever aplicativos JME (MIDP) atualmente é um grande desafio relacionado as questões de limitação e portabilidade entre os diversos dispositivos. Devido as diferentes implementações da especificação em cada dispositivo (de diferentes fabricantes), o visual e alguns comportamentos da aplicação (fontes, layouts, menus, scrooling etc) acabam ficando complemente diferente um do outro.

A Lightweight UI Toolkit foi desenvolvida de encontro com isso, oferecendo facilidades para criar aplicações com um novo visual (Themes) e comportamento padronizado em todos os diferentes dispositivos, introduzindo um novo paradigma de programação similar ao Swing dentro dos aplicativos MIDLETS. O toolkit atualmente pode ser usado sobre a CLDC1.1 MIDP2.0/CDC PBP/SE. Veja aqui o link para o site do projeto e aproveite para o ver o printscreen das belíssimas e revolucionarias GUI exemplos. Projeto bem promissor !!!!!! Vamos ver no que vai dar 🙂

Servlet 3.0 JSR 315

Postado em Atualizado em

O expert group da JSR 315 tem entrando em um grande impasse relacionado com as novas características sobre servlets e filters. Os membros estão em pleno debate sobre questões de segurança e flexibilidade relacionado com “deployed via annotations, discovered web.xml fragments or programmatically in Listeners discovered in TLD descriptors or web.xml.” Acompanhe aqui o andamento da discussão e fique antenado no que esta por sair nas próximas versões do novo JEE.

Combinação de JPA e EJB 3.0

Postado em Atualizado em

Para quem acompanhou na época e ascensão dos Core J2EE Patters sobre o modelo do EJB 2.1,….. agora pode acompanhar seu declínio provando que a especificação do EJB 3.0 e JPA vieram para tomar espaço no mercado. Leia aqui um artigo interessante sobre isso.

JEE M1- Adetec 24/04/08

Postado em Atualizado em

Neste post podemos trocar informações, comentários, sugestões e criticas durante o curso.

Vejam o post – Aplicativos Web com Java

EntityManager em Aplicativos Web Standalone

Postado em Atualizado em

Segue algumas das estratégias que podem ser utilizados na implementação de uma camada de persistência utilizando o JPA em aplicativos web standalone:

1. Abrir e fechar um EntityManager por operação de negocio (quando precisar)

  • Perde o cache de nível 1 chamada de “repeatable read”, ficando somente com o de nível 2.
  • Tem que implementar o equals and hashCode dos pojos usando chave de negócio, uma vez que eles desligados perdem a identidade de persistência.
  • Perde a carga de objetos LAZY, uma vez que quando o pojo é retornado para a camada de visão, ele ja esta desligado(detached) e o contexto de persistência fechado.
  • 2. Abrir e fechar um EntityManager por HttpRequest (Usando Filter Servlet + atributos de ThreadLocal)

  • Perde o cache de nível 1 chamada de “repeatable read”, ficando somente com o de nivel 2.
  • Tem que implementar o equals and hashCode dos pojos usando chave de negócio, uma vez que eles desligados(detached) perdem a identidade de persistência.
  • Mantém a carga LAZY uma vez que quando pojo esta sendo usando para renderizar a camada de visão, o contexto de persistência ainda esta aberta e somente será fechado pela volta da execução do filter.
  • 3. Abrir e fechar um EntityManager por HttpSession (Extendida)

  • Essa estratégia usa um listener de session para criar apenas 1 objeto de contexto de persistência por usuário quando a sessão dele é criada.
  • O cache de nível 1 e 2 é utilizada.
  • Pedidos assíncronos simultâneos de um mesmo usuário ajax transacionais NÃO são executados concorrentemente uma vez que o objeto EntityManager é thread-safe.
  • Não existe a necessidade de implementar equal e hashCode, uma vez que o contexto de persistência mantém a referencia de identidade dos objetos persistentes (obj1==obj2).
  • Pedidos assíncronos simultâneos de um mesmo usuário podem interromper as transações definidas dentro do EntityManager, uma vez que uma consulta descarrega o contexto de persistência no SGDB. (Nesse caso tem que alterar o comportamento padrão do FlushMode podendo aumentar o grau de complexidade da camada de persistência)
  • Exceptions ocorridas dentro do um único contexto de persistência, invalidarão o estado do objeto, tendo a necessidade de criar outro, ou seja problemas se ocorrer durante a utilização do sistema. (Pode ser contornado pela aplicação criando um novo objeto quando o fato acontecer).
  • Head Hush ou Head First Ajax ?

    Postado em Atualizado em

    Em fevereiro de 2006 a Head First lançou o livro sobre AJAX com o cod-nome Head Hush. E agora em julho de 2008, ela lançara o mesmo livro chamado Head First AJAX. A confusão aqui é que dentro da Head First existe uma outra série de versões simplificados e resumidas chamadas de Head Hush.

    E foi isto que aconteceu, Head Hush Ajax é apenas um livro resumido ao básico mesmo sobre AJAX e seus assuntos correspondentes….mas que agora no verão americano(julho) esta agendado a versão completíssima do livro sobre AJAX…….que esta prometendo muito !!!

    Veja aqui o artigo oficial bem humorado com sempre heheheheh (eu sempre me divirto de + com os personagens e seus comentários….), explicando toda esta confusão. Para quem ainda não se aprofundou no assunto vale a pena esperar por mais essa grande obra !! Eu concerteza estarei comprando para completar meus conhecimentos e a claro…..a coleção 🙂

    Se for AJAX com java EU VOOOO !!!!