Veja também:

• Oracle XE : Mudando a porta padrão HTTP
• Como jogar Call Of Dudy 4 MW em servidores do Brasil?
• WebLogic 10.x + Hibernate 3 (JPA) e base Oracle 9+
• [Adobe Flex] Definindo o foco na aplicação
• [Adobe Flex] comparando datas de maneira rápida e fácil

Twitter!

A última implementação da HibernateDAOFactory do módulo persist do DCF, agora permite que seus DAOs de entidade possuam propriedades injetadas diretamente do container de beans do Spring.

No exemplo que temos nos testes de projeto, temos o MockDAO, que possui uma propriedade String com nome ‘testeString’:

Note que no setter da propriedade, colocamos a anotação @Autowired, para recuperar esta String do container, e também associamos o Qualifier ‘testeString’.

No arquivo de beans do spring, basta adicionarmos um bean String com o id igual ao do qualifier:

Repare que o valor da String é ‘stringTeste’. Vamos ver em nosso teste agora se tal valor chega corretamente no DAO:

Uma coisa importante a se perceber, é que a chamada da DAOFactory permanece exatamente a mesma, mantendo assim a retro-compatibilidade com as outras versões, e apenas as injeções baseadas em anotações do Spring vão ser consideradas.
NÃO é necessário apontar o component-scan do Spring para o pacote de DAOs de sua aplicação. A injeção de beans adicionais é feita completamente a parte, seguindo o mesmo padrão de nome e de instanciação dos DAOs.

Qualquer dúvida, basta me procurar.

O projeto está no github, dentro do módulo persist do dclick-framework, ou diretamente no nexus da DClick.

Twitter!

JodaTime

Não existe segredo quando se fala da implementação de datas no Java: é ruim de usar. Alguns chegam a dizer que é errado usar inclusive, mas não serei tão extremo.
A API de datas do Java é ruim por vários motivos, como por exemplo, é mal documentada, não é Thread Safe, é difícil de manipular datas, e o comportamento nem sempre é o esperado.
Vamos ver como susbtituir a API de datas que vem Out of the Box no Java, por uma mais efetiva, amigável e confiável: JodaTime.

Lembrando do Calendar

Todo programador Java conhece o Calendar, e sabe que para usá-lo, basta seguir o Design Pattern singleton, ou seja, basta chamar o método de classe em Calendar que devolve a instância única do sistema para o Calendar.


Problema: não funciona.


Não funciona porque se a instância é singleton, e não utiliza threadlocking no código, então não é uma instância ThreadSafe. Logo toda vez que chamamos o getInstance() do Calendar, obtemos uma nova instância. Para ilustrar, crie um teste em JUnit 4 com o seguinte código:

Rode o teste e veja a barra do JUnit ficar vermelha. O comparador ‘==’ usado em objetos, compara pelo endereço de memória, o que deveria ser o mesmo se fosse seguido o padrão singleton de verdade.
Pra piorar, todos os métodos que alteram as intâncias do Date estão expostos (por mais que estejam depreciados) para mantêr compatibilidade com versões anteriores da VM. Portanto o Date também não é ThreadSafe, pois não existe controle de concorrência em sua implementação.
Agora vamos deixar o Date e o Calendar de lado, e vamos ao JodaTime.

DateTime

O JodaTime diferencia muito bem os conceitos de data, instante de tempo, período, etc. A classe mais básica (interface no caso) é a ReadableInstant. Não precisa dizer que todas as modelagens de data implementam essa interface, permitindo comparar todos os tipos de modelagem de tempo pontuais. Um período não descreve um único instante ou ponto no tempo, por exemplo.
DateTime é talvez o ReadableInstant mais conhecido, e funciona muito parecido com o Date do Java.
Fatores que tornam o DateTime mais amigável são: é ThreadSafe pois é imutável, é muito bem documentado, e é muto fácil realizar operações com data. Vamos escrever um pouco de código para entender o que se passa.
Comece criando um DateTime. Como no Java, este DateTime criado possui o instante atual do sistema. Em seguida para efeito de teste (o teste pode falhar dependendo de quando for executado), adicione um dia na data criada, e verifique que o novo date aponta para amanhã:

Repare que tive que reassociar o date para que ele pudesse ser alterado, afinal DateTime é imutável, o mesmo comportamento que o BinInteger possui. Repare também que pra adicionar um dia, basta chamar plusDays. Este método já se encarrega de fazer toda a lógica de adicionar um dia na data, como por exemplo mudar o mês ou ano se for preciso, por isso se esse teste for rodado no dia 31 de dezembro, ele irá falhar pois o DateTime irá adicionar mais um dia a data, e perceberá que se trata do ano seguinte, e portanto getDayOfYear irá devolver ’1′, e não ’366′ ou ’365′ como esperado.
O JodaTime também trata anos bissestos e horário de verão se for selecionado o fuzo correto.
Existe uma API bem completa em DateTime para manipular todos os campos possíveis da data, sendo assim fica muito mais fácil iterar ao longo dos dias, sem precisar delegar pro Calendar a tarefa, e depois recuperar o resultado.
Não vou abordar muito da API do JodaTime, pois está muito bem documentada e existem muitos exemplos nas internet. O objetivo desse post é tratar do assunto do próximo tópico.

JodaTime e Hibernate

Pior que manipular datas, é persistir datas. Cada banco persiste data do seu próprio jeito, e cada implementação de ORM trata o Date do seu próprio jeito. Mas se você está utilizando o Hibernate, o JodaTime tem uma solução de padronização pra você: JodaTime Hibernate.
Com o JodaTime Hibernate é possível mapear diversos tipos de representação de data em suas classes Java, com ou sem TimeZone, como String ou bigint, como período ou duração, etc.
Para se ter uma idéia do que é possível, basta verificar a documentação online.
E para utiliza é muito fácil. Imagine que você tenha uma entidade com um campo DateTime, que se chama entryDate, portanto temos o getter:

Para tornar este DateTime uma data que é padrão do banco que será utilizado, por exemplo, basta adicionar a seguinte anotação:

Estamos falando para o hibernate utilzar o tipo de coluna descrito pelo PersistentDateTime, e utilizar o mesmo para converter a data novamente para DateTime quando for recuperado.
Caso você esteja fazendo engenharia reversa de algum banco, recomendo ler a descrição de todos os tipo disponíveis pra fazer a melhor escolha.
Com isso conseguimos obter todos os benefícios do JodaTime em nossas entidades, facilitando controlar as datas no domínio de nossas aplicações.


Espero ter despertado sua curiosidade com o JodaTime. Na minha opinião é uma das melhores bibliotecas Java disponíveis, mas não quero falar muito sobre suas funcionalidades, pois um dos pontos mais fortes da biblioteca é a facilidade de se acostumar com ela, e principalmente utilizar todos seus recursos. Quero que vocês tenham um pouco desse gostinho .

Por @Gust4v0_H4xx0r

Veja também:

• Tutorial : JDJ : Adobe Flex & Java
• Voltando ao mundo HTML+JS e agora?
• [Flexmania 2011] Planejando e projetando – Dashboad : Flex + Java
• Lady Java
• [ Java Desktop ] Processamento de Imagens Digitais

Olá pessoal, que tal trabalhar com Adobe Flex e Java na cidade maravilhosa?

A Avanti Prima Engenharia está com oportunidades para trabalho com Adobe Flex/Java no Rio de Janeiro.

Segue abaixo informações sobre a vaga:

Experiência Exigida

• Experiência mínima comprovada de 3 anos no desenvolvimento de software na linguagem Adobe Flex, preferencialmente integrando com Java;
• Experiência em análise e modelagem de sistemas, utilizando UML;
• Conhecimento de padrões de projetos orientados a objetos;
• Conhecimento em Hibernate, JSF (front-end), EJB (back-end).
• Conhecimento em especificação de casos de uso;

Interessados, enviar seus CV para: stefan.horochovec@avantiprima.com.br ou para eric.sander@avantiprima.com.br

Olá, hoje vou mostrar como fazer um DAO Genérico no Java (contendo SaveOrUpdate, Remove, FindAll, FindByID) que pode ser usado por todos os DAOs. Facilitando a criação de novos projetos, podendo ser usado com a integração com o Adobe Flex através do RemoteObject.

Isto é para quem não quer usar nenhuma espécie de Framework (ex: Spring, que faz isso de uma forma mais genérica).

Primeiramente criei minha classe contendo todos os métodos (save, update, delete, find), para minha classe ficar “genérica” ao invés de receber as entidades específicas, recebe Object (pode passar as Entidades que o java consegue reconhecer). Após criar esta classe contendo os métodos, é só criar os DAOs extendendo da classe genérica, com isso já terá todos os métodos implementados. Podendo fazer validações específicas para cada DAO.

Vamos a prática:

Este é minha classe genérica contendo todos os métodos.
GenericDAO.java
Leia mais…

Olá.

A alguns dias escrevi um post sobre PHP + MongoDB e recebi um feedback muito positivo
então resolvi repetir a dose e mostrar um pouco da integração entre Java e MongoDB.

Na minha opinião essa é uma das principais vantagens do MongoDB em relação a outros bancos de dados NoSQL,
O MongoDB e extremamente fácil de se integrar com a maioria das linguagens.

Neste Post vou falar um pouco sobre o MongoDB e a integração com o java utilizando o Spring Data.
O MongoDB fornece o mongo-java-driver que atualmente esta na versão 2.6.X é uma API completa para acessar o MongoDB.
O Spring Data é um projeto recente, lançado em 2010, ele oferecer suporte a novas tecnologias não relacionais, suporte a extensões específicas a bancos de dados relacionais. Spring Data trabalha como uma camada intermediária entre seus POJOs e o MongoDB.

Nesse exemplo estou usando o maven para gerencias as dependências do projeto
Então alem das dependências habituais do projeto: Spring, JUnit e etc.. vamos precisar adiciona ao pow.xml as dependências do MongoDB e Spring Data

pow.xml

Feito isso as dependências do projeto estão configuradas e podemos partir para a configuração do spring.
A configuração é bem simples, nesse exemplo existem apenas 2 beans que configuram o MongoDB e Spring Data mongoTemplate e mongo

applicationContext.xml

O Spring Data oferece uma serie de anotações que permitem mapear o POJO de forma bem similar ao Hibernate/JPA
Contact.java

@Document(collection="contacts")
public class Contact 
    @Id
    private ObjectId id;
    private String name;
    private String email;

  //getter and setter methods 
  ...

E é através do mongoTemplate que vamos interagir com o MongoDB por exemplo :

@Autowired
MongoTemplate template;

// insere um novo registro		
template.insert("contacts", contact);

// insere/altera um registro
template.save("contacts", contact);

// remove um registro
template.remove(contact);

// lista todos os registros
List list = template.getCollection(collectionName, Contact.class);

Apesar do Spring Data suportar o JPA repository fiz uma implementação genérica para um repositório usando o Spring Data.

GenericRepositoryWithMongo.java – Repositório genérico

public abstract class GenericRepositoryWithMongo 

  @Autowired
  protected MongoTemplate template;
  protected Class targetClass;
  protected String collectionName;

  @SuppressWarnings("unchecked")
  public GenericRepositoryWithMongo() 
     this.targetClass = (Class) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
  

  @PostConstruct
  public void initCollection() 
    if(this.targetClass.isAnnotationPresent(Document.class))
      Document document   = this.targetClass.getAnnotation(Document.class);
      this.collectionName = document.collection();
    
    else
      this.collectionName = this.targetClass.getSimpleName().toLowerCase();
    
  }

  public List getCollection() 
    return template.getCollection(collectionName, targetClass);
  

  public void persist(T entity) 
    template.insert(collectionName, entity);
  

  public void merge(T entity) 
    template.save(collectionName, entity);
  

  public void remove(T entity) 
    template.remove(entity);
  

  public List findAll() 
    return getCollection();
  

  public long count() 
    return getCollection().size();
  
}

E então a interface do repositório e sua implementação

ContactRepository.java – Repositório de contatos

public interface ContactRepository 

    public Contact findByEmail(String email);

    public void persist(Contact entity);

    public void merge(Contact entity);

    public void remove(Contact entity);

    public List findAll();

ContactRepositoryImpl.java – Implementação do repositório de contatos

@Service("contactRepository")
@Repository
public class ContactRepositoryImpl extends GenericRepositoryWithMongo implements ContactRepository

	public Contact findByEmail(String email) 
	   Criteria criteria	 = Criteria.where("email").is(email);
	   Query query 	         = new Query(criteria);
	   return template.findOne(query, targetClass);
	
}

Realmente me surpreendi com a facilidade da integração usando o Spring Data
é um exemplo bem simples da integração porem mais da o caminho das pedras para quem esta se aventurando no mundo NoSQL.
Espero que seja util..

Para quem tiver o interesse deixei app no git
https://github.com/FabioBatSilva/spring-mongodb

Abraço e até a próxima….

Click aqui para ver o post Original

Fabio B. Silva
http://www.flexria.com.br

BlazeDS é uma aplicação Java opensource mantida pela Adobe, sob licensa GNU Lesser General Public License, Version 3 (LGPL v3), que fornece um conjunto de serviços, todos sobre o protocolo HTTP(Hyper Text Transfer Protocol), para permitir uma aplicação Flex fazer chamadas a serviços remotos Java, retornando os dados tanto de forma assíncrona como em tempo real.

Por utilizar o formato de dados binário chamado AMF(Action Message Format) para a serialiazação e deserialização de dados, a comunicação entre uma aplicação Flex e o servidor Web se torna muito otimizada. Existem estudos feitos comparando as diversas tecnologias, como o Jamesward, mostrando o potencial do AMF.

Outra grande vantagem quando usamos o BlazeDS é a facilidade de ter classe Java automaticamente convertida para uma classe ActionScript e vice-versa.

O BlazeDS pode ser baixado do site da Adobe em dois formatos:

1. Turnkey – Versão que já vem com exemplos e servidor tomcat pré configurado
2. Binary – Versão com os binários

Você pode optar também por fazer o download do código fonte. A documentação também está disponível neste link.


Entendendo os arquivos de configuração do BlazeDS
A estrutura de arquivos do BlazeDS é bem simples, quando descompactamos o blazeds.war, presente na versão binária, podemos ver a seguinte estrutura:

Devemos nos atentar a duas pastas. A pasta lib, que contém todos os jars necessários, e a pasta flex, que contém todos os arquivos de configuração do BlazeDS. Vamos ver o que cada arquivo significa:

1. services-config.xml: É neste arquivo que estão as principais configurações do BlazeDS como segurança, logging, serviços disponíveis (Canais), fábricas para a integração com Frameworks Java como Spring e EJB3 e as referências para os outros três arquivos de configuração.
2. remoting-config.xml: É nesse arquivo que iremos configurar os serviços Java para serem “consumidos” pela aplicação Flex. Sempre quando configuramos este arquivo, iremos trabalhar com o componente Flex chamado RemoteObject.
3. message-config.xml: Aqui é configurado tudo o que for relacionado com mensageria, sempre necessário quando trabalhamos com os componentes Flex Consumer e Producer. Um exemplo da utilização desta tecnologia seria fazer um bate bapo, ou até mesmo aplicações colaborativas, onde é desejável a iteração simultânea de diversos usuários.
4. proxy-config.xml: Além da possibilidade de utilizarmos o componente RemoteObject, o Flex disponibiliza mais duas formas de integração: O HTTPService e o WebService. Porém, por questões de segurança, os serviços só podem ser chamados quando os mesmos estão no mesmo domínio que a aplicação, ou que exista uma configuração específica que permita um cliente Flex fazer a consulta (esta configuração é feita por um arquivo chamado crossdomain.xml e está sempre no servidor onde está o serviço chamado). Caso uma das duas condições acima não seja satisfeita, deveremos utilizar o BlazeDS como proxy , e é ai que configuração deste arquivo se torna necessário.

Criando o seu primeiro projeto com o BlazeDS

Para criar o projeto iremos precisar de:

1. Eclipse Galileo JEE
2. FlashBuilder Plugin
3. BlazeDS 4 Binary
4. Tomcat 6

Feito os downloads e a instalação do Eclipse e FlashBuilder, vamos iniciar o FlashBuilder para criar o projeto.
Antes de criar o projeto, vamos configurar o Tomcat:

1. Nas preferências do Eclipse, vá em Server — Runtime Environments e clique em Add…
   
2. Na pasta Apache selecione Apache Tomcat v6.0 e clique em Next
   
3. Selecione a pasta onde você descompactou o Tomcat e clique em Finish
   

Feito a configuração do Tomcat, vamos criar o projeto:

1. Vá em File – New – Flex Project
2. Preencha os dados do primeiro passo como na imagem abaixo e clique em Next
   
3. Neste passo vamos configurar os dados do servidor. Deixe tudo configurado como na imagem e clique em Next
   
   
   Para selecionar o “Target Runtime”, clique em New e depois escolha o Apache Tomcat 6, como na imagem abaixo.
   
4. No último passo não será necessário mudar nada, clique em Finish
   

Agora vamos criar a classe Java que terá o serviço para retornar a string “HelloBlazeDS”

1. Crie uma classe Java br.com.dclick.service.RemotingService
   
2. Crie o serviço:

   1 2 3 4 5 6 7 8

   package br.com.dclick.service; public class RemotingService { ? ? public String sayHello() { ? ? ? ? return “HelloBlazeDS”; ? ? } ? ? }

Agora vamos configurar o BlazeDS para disponibilizar o serviço que acabamos de criar.

1. Abra o arquivo remoting-config.xml que está na pasta WebContent/WEB-INF/flex
2. Para que seja possível chamar os métodos da classe Java, precisamos configurar um destination. Isso é necessário para cada classe Java.
   O arquivo fica assim:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

   xml version=“1.0″ encoding=“UTF-8″?> “remoting-service” class=“flex.messaging.services.RemotingService”> ? ? ? ? ? ? “java-object” ? ? ? ? ? ? class=“flex.messaging.services.remoting.adapters.JavaAdapter” ? ? ? ? ? ? default=“true” /> ? ? ? ? ? ? ? ? “my-amf” /> ? ? ? ? “blazeServices”> ? ? ? ? ? ? ? ? ? ? br.com.dclick.service.RemotingService ? ? ? ? ? ?

Vamos colocar na aplicação a chamada para o servidor.

1. A primeira coisa que precisamos fazer é configurar o RemoteObject. Fazer isso é muito simples:

   1 2 3 4 5

   ? ? ? ? ? ? ? ? “services” destination=“blazeServices” ? ? ? ? ? ? ? ? ? ? ? ? result=“services_resultHandler(event)” ? ? ? ? ? ? ? ? ? ? ? ? fault=“services_faultHandler(event)” /> ? ?

   
   Alguns detalhes:
   
   * Perceba que a propriedade destination aponta para o destination que configuramos no arquivo remoting-config.xml
   
   * Precisamos declarar um id para poder referenciar o RemoteObject
   
   * Adicionamos um ResultHandler para tratar o resultdo do serviço
   
   * Adicionamos um FaultHandler para tratar a falha do serviço

2. Os Handlers ficam assim:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

   ? ? ? ? ? ? ? ? [CDATA[ ? ? ? ? ? ? import mx.controls.Alert; ? ? ? ? ? ? import mx.rpc.events.FaultEvent; ? ? ? ? ? ? import mx.rpc.events.ResultEvent; ? ? ? ? ? ? protected function services_resultHandler(event:ResultEvent):void ? ? ? ? ? ? { ? ? ? ? ? ? ? ? Alert.show(event.result.toString()); ? ? ? ? ? ? } ? ? ? ? ? ? protected function services_faultHandler(event:FaultEvent):void ? ? ? ? ? ? { ? ? ? ? ? ? ? ? Alert.show(event.fault.message); ? ? ? ? ? ? } ? ? ? ? ]]> ? ?

   
   Alguns detalhes:
   
   * A propriedade result do evento ResultEvent vai conter o resultado do serviço. No nosso caso o serviço retorna uma String “HelloBlazeDS”
   
   * A propriedade fault do evento FaultEvent contém os detalhes do erro.

3. A última coisa é chamar o serviço. Vamos fazer isso no evento creationComplete, como segue:

   1 2 3 4

   ? ? ? ? protected function application1_creationCompleteHandler(event:FlexEvent):void ? ? ? ? ? ? { ? ? ? ? ? ? ? ? services.sayHello(); ? ? ? ? ? ? }

4. A aplicação inteira fica assim:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

   ? ? ? ? xml version=“1.0″ encoding=“utf-8″?> “http://ns.adobe.com/mxml/2009″ ? ? ? ? ? ?? ? xmlns:s=“library://ns.adobe.com/flex/spark” ? ? ? ? ? ?? ? xmlns:mx=“library://ns.adobe.com/flex/mx” minWidth=“955″ minHeight=“600″ ? ? ? ? ? ?? ? creationComplete=“application1_creationCompleteHandler(event)”> ? ? ? ? ? ? [CDATA[ ? ? ? ? ? ? import mx.controls.Alert; ? ? ? ? ? ? import mx.events.FlexEvent; ? ? ? ? ? ? import mx.rpc.events.FaultEvent; ? ? ? ? ? ? import mx.rpc.events.ResultEvent; ? ? ? ? ? ? protected function services_resultHandler(event:ResultEvent):void ? ? ? ? ? ? { ? ? ? ? ? ? ? ? Alert.show(event.result.toString()); ? ? ? ? ? ? } ? ? ? ? ? ? protected function services_faultHandler(event:FaultEvent):void ? ? ? ? ? ? { ? ? ? ? ? ? ? ? Alert.show(event.fault.message); ? ? ? ? ? ? } ? ? ? ? ? ? protected function application1_creationCompleteHandler(event:FlexEvent):void ? ? ? ? ? ? { ? ? ? ? ? ? ? ? services.sayHello(); ? ? ? ? ? ? } ? ? ? ? ]]> ? ? ? ? ? ? ? ? “services” destination=“blazeServices” ? ? ? ? ? ? ? ? ? ? ? ? result=“services_resultHandler(event)” ? ? ? ? ? ? ? ? ? ? ? ? fault=“services_faultHandler(event)” /> ? ?

Agora só falta fazer o deploy da aplicação e subir o servidor.

1. Vá em Window – Show View – Other. Na janela que abrir, digite Servers e clique OK
   
2. Na view Servers, clique com o botão direito em Tomcat v6.0 e selecione Add and Remove…
3. Selecione a aplicação HelloBlazeDS e clique em Add e depois Finish
   
4. Na view Servers, clique com o botão direito em Tomcat v6.0 e clique em Run

Agora é só executar a aplicação e ver o resultado:

Isso é tudo, guarde esse projeto configurado para ser usado nos próximos posts.