Diego Pacheco Tech blog

é um framework java feito na arquitetura REST . Podemos conferir a lista de features do Restlet aqui: features . O Restelet vem como uma alternativa completa para API Servlet. Ainda mais agora a que vai entrar uma JSR para Rest em java. Confira no Link: JSR311 . Fiz alguns testes com o restlet nas partes de Guard,Invocação de Webservices com JSon e bowser list. Talvez mais para frente eu poste algum desses teste aqui. Na minha opinião nesses itens que testei achei bem simples e intuitivo o uso do restlet. Agora é esperar essa JSR311 começar a bombear. Mas eu acredito que o restlet será uma boa pedida.

O Steve Anglin escreveu um artigo no onJava sobre os 10 mais comuns erros em relação ao Spring. São erros conceituais. Neste Artigo ele traz dados de empresas como bancos, empresas governamentais, empresas aéreas. A empresa Voca da inglaterra fez em 2005 mais de 5 bilhões de transações utilizando Spring. Leiam o artigo do Steve Anglin, acredito que irá esclarecer muitas coisas.

Mais uma vez: Spring Framework .Eu confesso que tenho uma certa queda por este framework, mas não poderia ser diferente o Spring é uma excelente solução com ótimo suporte, documentação impecável, Poderia escrever 1.000 linhas de elogios ao Spring aqui. Mas o ponto agora é JMS Assíncrono verdadeiramente baseado em POJOs, Essa integração do Spring com JMS acontece muito bem. No exemplo do Mark Fisher Message Driven POJOs , ele mostra como construir essa solução, utilizando JMSTemplate do Spring. Recomendo a leitura e tentar fazer o exemplo que ele mostra, eu fiz é bem simples e rápido. Depois Mark escreveu um outro artigo Request-Reply JMS with Spring 2.0 este por sua vez se baseia no anterior porem, ele mostra uma outra abordagem utilizando: JmsInvokerServiceExporter e JmsInvokerProxyFactoryBean que nos possibilitam trabalhar com JMS de maneira que o Spring abstrai totalmente o modelo de Queue Request/Response. Eu fiz os dois exemplos que ele mostra, achei muito fácil e acredito ser...

O Design Pattern DAO é um padrão para se encapsular o acesso a banco de um determinado Objeto. Existem muitas criticas sobre esse padrão, dentre elas a que você prolifera muitas classes do estereótipo DAO pelo seu projeto e ma verdade elas só tem um conjuntos de métodos find*. Eu concordo com isso, achei um artigo no Developer Works da IBM, que na minha modesta opinião é uma ótima solução. Você cria uma DAO Genérico e depois só precisa criar interfaces e named querys no Hibernate. A solução envolve Hibernate e Spring + AOP. É Muito bem bolada. Recomendo a leitura do artigo, no final do artigo tem um link para os fontes. Vou resumir o que a solução faz: Existe uma interface GenericDao que define o comportamento de um DAO, temos uma implementação padrão para essa interface que é a classe GenericDaoHibernateImpl essa classe implementa mais três interfaces: FinderExecuter que é o que o interceptor do Spring ira interceptar. E a outra é FinderArgumentTypeFactory Que define uma factory...

Gostaria de recomendar a leitura do artigo no ONJava sobre as 12 melhores praticas sobre configuração de XML no Spring. Estou esperando ansiosamente que o Spring possibilite fazer sua configuração através de annotations, enquanto esse dia não chega é valido utilizar o xml da maneira mais correta. O Link para o artigo está aqui!

O DWR permite Javascript no browser interagir com o servidor e a manipular paginas com resultados. DWR Significa: Direct Web Remoting, ele é um framework para fazer a conversação de paginas com o lado server, utilizando Ajax. Vou mostrar um exemplo de como integrar o DWR com o Spring Framework . web.xml: Aqui é um web.xml padrão onde definimos os servlets do DWR e Spring. <?xml version="1.0" encoding="UTF-8"?> <web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">    <!-- Registro do Servlet do DWR -->       <servlet>       <servlet-name>dwr-invoker</servlet-name>     ...

Ao falar nesse assunto provavelmente venha a cabeça de cada um... VELOCITY da apache. Mas hoje vou "falar" de Freemaker . O Freemaker é muito semelhante ao velocity, eles tem o mesmo propósito. A partir de um template e objetos Java, é gerado um output que pode ser html,pdf,txt,classes java,arquivos de configuração,etc... Esse framework se destaca em relação ao velocity por que: Tags mais evoluidas estilo java 5.0 Mas simples de programar o template Transformation Template Bean Wrapper Method Call Transformation: Com esse recurso podemos especificar uma tag e ai efetuar um determinado processamento sobre todo o conteúdo que estiver sobre essa tag. Vou dar um exemplo de um Transformation que passa o texto para maiusculo e coloca em negrito(html). Classe java class UpperCaseTransform implements TemplateTransformModel {     public Writer getWriter(Writer out, Map args) {        ...

Ao ler o artigo A Definition of Closures do Neal Gafter Criador do Google Calendar e ver sua apresentação no JavaPolis6 Acredito que o java será melhor com Closures. A entrada de Generics no java 5.0 deixou o desenvolvedor com pais poder, apesar de o código ficar consideravelmente mais complicado. Acredito que com Closures o código ficará mais complicado ainda en determinadas situações mas o poder do desenvolvedor será mais forte. Vejam a apresentação do Neal no JavaPolis que valhe a pena.

Recomendo a leitura do artigo The top Java EE best practices , eu quero comentar os dois primeiros itens da lista de 19 melhores praticas. Use MVC e não re-invente a roda. Use MVC: Sempre use MVC. Eu trabalhei em uma empresa que entre a camada de apresentação e a camada de modelo sempre trafegava os dados em xml e depois fazia o bind para um objeto, não gosto desse modelo pois o xml deve ser usado para comunicação entre tecnologias distintas, não entre camadas da mesma tecnologia como view e model. Era um inferno isso além de gerar um over-head não tinha ganho algum. Não re-invente a roda: Acho que essa é a grande lição para as empresas e os desenvolvedores, não cometa os mesmos erros que as outras pessoas cometeram aprenda com o passado dos outros. No artigo fala que varias empresas fizeram seu próprio "framework" de GUI(camada da view do MVC) isso também é um grande erro, pois passando por aquilo que muitas outras pessoas já passaram e sofrendo a mesma dor. Use frameworks j...

Um dos freatures interessantes do java 6.0(Mustang) é a Java Compiler API resultante da JSR 199 . Vou mostrar um exemplo de como usar essa API, esta api nos permite usar a compilação de artefatos java de uma maneira mais elegante sem precisarmos invocar o javac via algum CLI da vida. Além de proporcionar compilação de código java em uma String em memória e listeners java compilação. Esta é a classe java que eu quero compilar. package org.diegopacheco.java6comilerapi.model; public class Hello {      public static void main(String[] args) {           System.out.println("Ola mundo");      } } Este é a classe java que irá compilar a classe Hello.java package org.diegopacheco.java6compilerapi.util; import java.io.File; import java.io.IOException; import javax.tools.JavaCompiler; import javax.tools.ToolProvider...

Pessoal talvez vocês em uma primeira impressão achem graça disso, mas acredito que nem todos os desenvolvedores java conhecem bem esses padrões. Segue o link de referencia: code conventions Por que isso? Esse dias ao conversar com outros desenvolvedores e ao ver códigos via algumas coisas que me deixaram inquieto como: public boolean validaCPFandCNPJ(String arg0){...} public class CNPJ{...} Segundo o documento da Sun esses dois exemplos estão errados. O correto seria: public boolean validaCpfAndCnpj(String arg0){...} public class Cnpj{...} Para métodos é preciso respeitar o camelCase. Mas uma dais coisas mais bizarras que eu via foi uma classe da oracle que vem no driver jdbc deles o jdbc14.jar tinha uma classe com esse nome: STRUCT olha só que legal isso(ironia rsrsrs): STRUCT struct = new STRUCT(); Horrível... Mas a sun, dentro do jdk e da API também tem alguns nomes esdrúxulos. A Nomenclatura e padrão de codificação é muito importante, leiam esse documento e sigam. Se não que Crom...

O XFire é a proxima geração de frameworks SOAP com um modelo de mensagens leves usado para integrar mensagens SOAP via STAX. Ele tem uma integração muito boa com o Spring Framework . Vou mostrar um exemplo de como fazer isso. primeiro passo é definir uma interface neste exemplo vou definir a interface hora. package org.diegopaheco.springxfire.model; import javax.jws.WebService; @WebService public interface Hora {   public String getDateTime(); } Como vocês devem ter percebido eu só usei a annotation @WebService no XFire. Agora vamos criar um serviço que implementa essa interface. package org.diegopaheco.springxfire.model; import java.util.Date; import javax.jws.WebService; @WebService(serviceName = "HoraService", endpointInterface = "org.diegopaheco.springxfire.model.Hora") public class HoraImpl implements Hora {      @SuppressWarnings("deprecation") ...

Em um projeto java, normalmente, usamos java doc para documentação de código/api. Algumas vezes os programadores mais preguiçosos não fazem esse papel e a documentação fica incompleta e em muitas vezes ela nem existe. Essa ferramenta da Sun Sun Doc Check Doclet Gera estatísticas sobre os fontes de um projeto java e assim podemos ver quantos artefatos,quais,como estão documentados. Assim podemos ter um controle e garantir uma boa documentação e o uso correto de java doc. Valhe a pena seguir o padrão de documentação java . Para usar a ferramenta é simples, só precisamos colocar o jar doccheck.jar no classpath e utilizando ant fazemos a geração, segue um script de exemplo. <project name="Sundoccheck-test" default="all" basedir=".">      <!-- This build file compiles the Doc Check source files,        builds a library ...

Pessoal fiz um "programinha" em java que acredito que resolve o problema da formatação dos códigos aqui. Para testar em baixo vai um xml do ant:      <!-- Generate Javadoc -->      <target name="javadoc" description="Generates the javadoc">           <javadoc bottom="${projectname} by ${author} - ${copyright}" destdir="${api}" doctitle="Javadocs: ${projectname} ${version}" private="false" version="false" windowtitle="Javadocs: ${projectname} ${version}" classpathref="base.path">                <sourcepath>                ...