Testes com DBUnit & HSQLDB

Olá Pessoal, 

Hoje veremos como deixar nossos testes com DBUnit usando o HSQLDB. O motivo que queremos rodar o banco em memoria, ou seja, evitarmos de termos que ter o banco rodando para executar os testes, o mesmo será iniciado somente quando os testes forem executado. Como você pode observar no último post, sempre temos que ter o MySql rodando para que as coisas funcionem e  ter essa dependência no dia-dia enquano estamos desenvolvendo é ruim, pois vamos exigir que cada desenvolvedor tenha que ter o MySql instalado na maquina etc. Não queremos isso. Queremos que ele faça o checkout do código e possa rodar. 

Lets go…

Starting…

Como já falado no post  anterior vimos como automatizar nossos testes usando DBUnit + Mysql, porém o que vimos de ruim é o fato de ter sempre o serviço do MySql rodando. E se quisermos rodar isso em memoria, como fazer? O HSQLDB nos dá uma mãozinha para rodar nossos testes com o HSQLDB, é muito simples, basta alterarmos o hibernate.cfg.xml e ter o .jar do HSQLDB adicionado ao projeto.

Vou considerar que você tem o projeto anterior, mas caso não tenha, siga os passos do primeiro post e mude apenas o arquivo do hibernate.cfg.xml.

1. O primeiro passo é criar o arquivo hibernate.cfg.xml com as configurações do banco onde os testes serão executados.

<hibernate-configuration>

<session-factory>

<property name=“hibernate.connection.driver_class”>org.hsqldb.jdbcDriver</property>

<property name=“hibernate.connection.url”>jdbc:hsqldb:mem:db</property>

<property name=“hibernate.connection.username”>sa</property>

<property name=“hibernate.dialect”>org.hibernate.dialect.HSQLDialect</property>

<property name=“hibernate.show_sql”>true</property>

</session-factory>

</hibernate-configuration>

Pronto, feito isso basta rodar os testes novamente e done. O resultado é Green .  Simples, não? Assim tiramos a dependência do MySql.

Vou ficando por aqui… Essa foi fácil.

Abraços, see ya!!

Criando GenericDAO e DAOFactory em poucos passos

Ola pessoal,

No post de hoje vamos ver como criar genericDAO e DAOFactory  em poucos passos. O objetivo maior aqui é colocar a mão na massa. Os conceitos DAO Design Pattern não serão abordados, pois o que não falta é explicação na internet sobre o assunto. Vou considerar que você sabe conceitualmente um DAO, mas que nunca implementou  de forma genérica.

Lets go…

 

Primeiro passo

Cria a interface GenericDAO :

public interface GenericDAO<T,Type extends Serializable> {

void beginTransaction();

void commitTransaction();

void save(T entity);

void delete (T entity);

List<T> listAll();

}

O código acima usa apenas o recurso de generics do Java 5, deixando a interface que extends dizer qual será o tipo para T e o para Type.

O que significa cada um?

Simples: o T será a classe, ou seja, a entidade. O Type representará o tipo que usaremos para o Id da entidade. Você pode estar se perguntando pq a letra T e a palavra type. Apenas segui uma convenção, mas poderia ser qualquer outra letra ou nome.

Agora precisamos criar a interface dos nossos DAO, que nesse caso teremos as seguintes interfaces: ClientDAO e AccountDAO.

public interface AccountDAO extends GenericDAO<Account, Long>{

}

public interface ClientDAO extends GenericDAO<Client, Long> {

}

Observe que nas nossas interfaces é que definimos para qual entidade ela está associada e qual será o tipo do nosso ID.

É nessa interface que colocamos os métodos específicos para o nosso DAO.

Abstract HibernateDAO

Criaremos uma classe abstract que vai implementar o métodos abstract da interface GenericDAO. E nossas classes concentras vão extends a HibernateDAO como veremos a seguir. Mas antes disso precisamos criar uma classe utilitária que chamei de HibernateUtil, que terá o método para obtermos a sessão, iniciar a transação, commit, etc.

public class HibernateUtil {

private static SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();

private static ThreadLocal<Session> threadLocal = new ThreadLocal<Session>();

public static Session getSession() {

Session session = threadLocal.get();

if (session == null) {

session = sessionFactory.openSession();

threadLocal.set(session);

}

return session;

}

public static void beginTransaction() {

getSession().beginTransaction();

}

 public static void commitTransaction() {

getSession().getTransaction().commit();

public static void rollBackTransaction() {

getSession().getTransaction().rollback();

}

public static void closeSession() {

getSession().close();

}

}

E na classe HibernateDao temos o código a seguir:

public abstract class HibernateDAO<T, Type extends Serializable> implements GenericDAO<T, Type>{

private Class<T> persistentClass;

public HibernateDAO(Class persistentClass) {

super();

this.persistentClass = persistentClass;

}

@Override

public void beginTransaction() {

HibernateUtil.beginTransaction();

}

@Override

public void commitTransaction() {

HibernateUtil.commitTransaction();

}

@Override

public void save(T entity) {

HibernateUtil.getSession().saveOrUpdate(entity);

}

@Override

public void delete(T entity) {

HibernateUtil.getSession().delete(entity);

}

@Override

public List<T> listAll() {

HibernateUtil.beginTransaction();

Criteria criteria = HibernateUtil.getSession().createCriteria(persistentClass);

return criteria.list();

}

}

Observe que implementamos todos os métodos da GenericDAO, assim a classe que extends já tem a implementation done, ou seja, aquilo que é comum para qualquer  classe DAO já vai estar implementado e disponível na classe pai.

Concrete DAO

Agora vamos criar a classe concreta que terá a implementação específica para cada DAO.

class HibernateClientDAO extends HibernateDAO<Client, Long> implements  ClientDAO {

public HibernateClientDAO(){

//                           we passing the entity for super class

super(Client.class);

}

}

Como não temos nada de específico para implementar da interface ClientDAO deixaremos o código assim. Observe que no construtor passei qual será o tipo T, que nesse caso será a class do Client.

DAOFactory

Agora vamos criar um DAOFactory que será responsável por criar as instâncias das classes Hibernate. A classe DAOFactory será abstract e tendo apenas um método implementado que será o getFactory, o qual terá como objetivo simplesmente de retornar uma instância da classe.

public abstract class DAOFactory {

private static final Class FACTORY_CLASS = HibernateDAOFactory.class;

public static DAOFactory getFactory(){

try {

return (DAOFactory) FACTORY_CLASS.newInstance();

} catch (InstantiationException e) {

// TODO Auto-generated catch block

throw new RuntimeException();

} catch (IllegalAccessException e) {

// TODO Auto-generated catch block

throw new RuntimeException();

}

}

public abstract ClientDAO getClientDAO();

public abstract AccountDAO getAccountDAO();

}

Em seguida adicionamos os métodos que retornam a instância para as classes que implementam as interfaces ClientDAO e AccountDAO.

Agora teremos uma classe que implementa os métodos do DAOFactory, que será a classe HibernateDAOFactory.

public class HibernateDAOFactory  extends DAOFactory{

@Override

public ClientDAO getClientDAO() {

return new HibernateClientDAO();

}

@Override

public AccountDAO getAccountDAO() {

return new HibernateAccountDAO();

}

}

Observe que apenas instanciamos as classes para cada DAO. Agora vamos criar  HibernateAccountDAO

class HibernateAccountDAO extends HibernateDAO<Account, Long> implements AccountDAO {

public HibernateAccountDAO() {

super(Account.class);

}

}

E para testar, criaremos uma classe com o método main:

public class MainBank {

public static void main(String[] args) {

//                           getting instance of the factory

DAOFactory daoFactory = DAOFactory.getFactory();

//                           getting intance of clientDAO and starting transaction

daoFactory.getClientDAO().beginTransaction();

ClientDAO clientDAO = daoFactory.getClientDAO();

Client client = new Client();

client.setName(“Camilo Lopes”);

//                           creating object of the entity

Account checkigAccount = new Account();

checkigAccount.setAccountType(AccountType.CHECKING_ACCOUNT);

//                           associate acocunt with the client

checkigAccount.setClient(client);

//                           money available in account

checkigAccount.setBalance(BigDecimal.ONE);

client.getAccount().add(checkigAccount);

//                           saveing in hibernate session

clientDAO.save(client);

AccountDAO accountDAO = daoFactory.getAccountDAO();

accountDAO.save(checkigAccount);

//                           commit

clientDAO.commitTransaction();

}

}

Resultado

É isso ai pessoal, espero que tenham gostado. Vou ficando por aqui. 

See ya!!!

Lançamento livro: TDD na Prática

Olá Pessoal!
É com muita felicidade que venho compartilhar com vocês mais esse “filho”. Eu não sei nem por onde começar de fato. Mas que tal pelo inicio?
Bom, a seguir falo um pouco da história dele (como todo livro meu sempre tem uma história real por trás), porque escrevi, quem pode ler,  sorteio etc Vou buscar ser bem breve..
Lets go…
Agradecimentos
Fazer esta parte aqui nunca é fácil, pois são várias pessoas que contribuem para uma obra como esta: amigos, colegas de trabalho, familiares, amigo virtual, etc. E lembrar de cada um não é uma tarefa fácil. Sendo assim, estarei destacando aqueles que vieram em memória no momento que escrevo este trecho.  Aqueles que contribuíram e acabei esquecendo, peço que me perdoem.
Primeiro, não poderia esquecer o meu colega de trabalho Gustavo Knuppe. Apesar dele não saber que estava escrevendo este livro, foi responsável por muitas mudanças que fiz na forma de abordar o assunto de TDD, principalmente em um artigo, no qual Knuppe foi o revisor, e nesse processo sugiram várias e boas sugestões no artigo produzido que aproveitei para utilizar neste projeto.
Um amigo que não poderia deixar de fora é o Alberto Leal. Eu diria que meu contato com mundo Agile começou devido a uma apresentação sobre refactoring que o Leal fez em alguns minutos via MSN e depois desse dia fui me envolvendo mais e mais com a técnica e quando conheci TDD e liguei o passado com o presente vi que ter conhecido refactoring com o Alberto fez uma diferença grande. Obrigado meu amigo!
À minha namorada Ellis Ribeiro, que teve a paciência e dedicação em revisar a parte ortográfica e dar sugestões de melhoria na estrutura do livro 🙂
Como tudo começou… (Era uma vez….)
Bem, primeiro nunca imaginei que um dia eu escreveria um livro sobre TDD, independente de que foco este teria. Até porque eu não sabia nada do assunto até inicio de 2010, apenas ouvia. Tinha tentado usar algumas vezes antes e fracassei em todas elas. Nunca entendia de fato como fazer os unit tests, muito menos escreve-los primeiro, mas fiquei com aquilo na cabeça. Todos (Kent Beck, Martin Fowler, Guilherme Silveira, etc) falam e conseguem, daí eu me perguntava: “o que eu estou fazendo de errado? Não vou desistir de entender direito.”  Dai passou o tempo, tive que voltar a estudar devido a um projeto que precisei trabalhar em 2010 e tinha que escrever unit tests para as coisas darem certo e então fui estudando, começei a ler e pesquisar com mais detalhe. Lembro que o primeiro post que li sobre o assunto foi do Guilherme Chapiewski. Fui navegando para outros blogs, tentando entender a mecânica e praticar. Comecei a pegar o ritmo, mas confesso que naquele momento não sabia que eu fazia TDD na veia, era complicado, pra mim era código com um framework que eu testava o que escrevi. Mas cada vez que programava gostava do resultado, ficava viciado, daí decidi me aprofundar mais no assunto, e fui buscar referências “for dummy”, tanto em português quanto em inglês. Achei? Não, pois identifiquei os seguintes problemas nas obras publicadas sobre o assunto na época:
1. Era necessário ter uma certa experiência (nem que fosse muuuito básica) com a mecânica de unit test;
2. Os livros eram longos e poucos práticos para iniciantes, com exemplos esquisitos que ao término da leitura sentia falta de algo mais concreto para praticar e dizer: ‘entendi de fato com a mão na massa’. Enfim, faltava uma direção melhor para iniciantes.
E foi quando despertou de sair anotando tudo que ia aprendendo, tanto aquilo que deu certo quanto o que deu errado também. Meses depois (no final de 2010), por “ironia” do destino caiu no meu caminho o meu primeiro projeto, o qual usariamos TDD. Mesmo sendo pequeno ajudou muito, digo que foi onde tudo começou de fato, com erros e acertos, mas foi gratificante o resultado. Dai fui para um outro mais arrojado, de 1 ano, e TDD foi a base para podermos entregar o código com qualidade, menos bug, menor custo de manutenção e respeitando os prazos. Tudo isso me fez refletir. Um dia parei e olhei para tras e perguntei: “O que aprendi até hoje? Que tal criar um livro sobre o assunto? Aliás, usar minhas anotações, experiência adquirida, para ajudar quem está querendo entrar nesse mundo?” Observei nos fóruns e comunidades Java que muitos tinham vontade de aprender TDD, outros tinham tentado e fracassado, alguns nem sabiam por onde começar.
 Enfim, todos os problemas que passei eram bem recorrente para todo iniciante. E foi aí que nasceu o meu livro “TDD na Prática”. Essa é a história dele.
Quem pode ler?
Essa é uma pergunta muito comum: “será que devo comprar?” Eu digo sempre o seguinte: compre o livro se você:
1. Conhece bem o básico do Java e Orientação a objetos. Olha o que eu estou falando, conhece bem JAVA e não JEE. Iniciantes ainda fazem confusão com as siglas do Java (não deveria, pois a primeira lição é saber as diferenças);
2. Sabe o que é unit tests ou tem ideia de para que serve;
3. Sabe a diferença entre unit test x Junit;
4. Quer de fato aprender TDD e saber que, no inicio, será um caminho duro, sofrido, pois não é só sentar na máquina e sair codificando. É uma forma diferente de pensar, codificar, resolver problemas, que no resultado final isso é transparente para quem olha sua aplicação e diz: “Essa eu digo 100% que foi feito com TDD, mas essa não”. A olho nú não é possível dizer isso.
5. Gosta de desafios e quebrar a cabeça;
Se você se encaixa nos pontos acima, pode adquirir um exemplar, caso contrário, eu diria que não compre :).
Como o livro está estruturado?
Bem, para quem conhece meus livros sabe que sou bem informal na escrita e gosto de dar a sensação ao leitor que estamos mais batendo um papo que lendo um livro em si. Com esse não será diferente, pois é meu jeito natural de escrever. Mas o que eu coloquei no livro?
Bom, quando começei a escrever a primeira pessoa que eu pude me espelhar era eu mesmo, aquele cara que não sabia:
  • – nada de TDD na prática, só ouvia falar;
  • – conceitos de Agile, muito abstrato ou quase nenhum;
  • – tanta sigla, termos TDD, Mocks, Mockito, Junit, refactoring que na prática, juntando tudo no “liquificador”, nunca sabia se o resultado final era de fato o esperado;
  • – e um cara que não sabia programar usando unit test; Alias, mal entendia uma classe que tinha métodos com as anotações @Test. Me perguntava “pra que realmente isso serve? como pode agregar valor na aplicação?” Só ouvia as pessoas falarem: “É bom”. “Funciona”. “Usa isso que vai ser show”, “Seus problemas acabaram, use unit test”. Mas no fundo não entendia como, e tive que aprender isso sozinho.
Então o livro segue uma ordem que, a depender em que nível você está, pode ir lendo sequencialmente. Eu diria que se é bem iniciante mesmo, vá na ordem sequencial, mas se você já sabe mocks, usar o JUnit, etc, pode pular alguns e ir para o qual lhe interessa de imediato.
Coloquei exercícios para serem feitos com o objetivo de forçar o leitor a exercitar o que aprendeu sobre TDD de formas diferentes. Vamos começando em um nível com a minha ajuda, mas depois deixo você ir sozinho, tomando suas decisões de quais testes escrever. Isso ajuda a ganhar confiança naquilo que está fazendo, o que no inicio com TDD todos se sentem desconfortável, inseguros e se perguntando: “será que estou fazendo a coisa certa? É isso mesmo?”. Enfim, espere exercícios um pouco diferentes do que você está acostumado a fazer no dia-dia. Também compartilho com o leitor como eu faço TDD e a gente vai vendo o que da certo e não da. Em alguns exercícios há respostas, para depois o leitor comparar e ver como resolvi. Não quer dizer que o seu tem que ser igual ao meu, cada um resolve de uma forma. O objetivo é que você tenha feito realizando os testes primeiro. Mas há outros que não temos a resposta. Fiz esses para que você possa olhar para o problema e garantir que atendeu ao requisito, ou seja, resolveu de fato usando TDD sem ter outra solução para preparar. Isso ajuda a ter mais confiança no que você entrega, já que todo “TDDista” sempre vai ouvir a seguinte frase: “Isso não funciona”, “Isso é coisa de nerd”. “Só funciona no mundo do Kent Beck e Martin Fowler”. Mas acostume-se com esses e outros comentários, faz parte do dia a dia, e o melhor de tudo: não se irrite. Há um capítulo que explico o Junit, Mocks, refactoring, falo rapidamente sobre Agile e Scrum.
Onde adquirir um exemplar?
Acredito que, dentro de uma semana no máximo, o livro estará disponível nas melhores livrarias, como: Saraiva, Cultura, Fnac, etc. E nas lojas virtuais: livrosdeprogramacao.com, submarino.com.br, americanas.com.br  etc.
No site da editora você pode comprar: www.lcm.com.br.
Formato do livro:
O livro será disponibilizado no formato impresso (R$ 36,80) e e-book(R$ 27,80). A versão ebook só será vendida pelo site da editora.
SlideShare
Disponibilizei no slideshare alguns capítulos do livro.
Sorteio
Você tem até 02/12/2012 para realizar o seu cadastro. No dia 03/12/2012 divulgarei o resultado.
Regras:
  • – Não é permitido realizar 2 cadastros. E-mails duplicados e a pessoa não estará mais participando do sorteio. Então façam apenas 1 cadastro por e-mail. Lembrando que deve ser um e-mail válido, pois o contato para confirmação dos dados será feito pelo e-mail cadastrado, e o ganhador tem até 48hrs para responder, a partir da data de recebimento. Caso contrário, um novo sorteio será feito;
  • – O livro será enviado para o endereço informado no cadastro. Então coloque o endereço completo + ponto de referência.
Atualização: 
O ganhador poderá escolher se deseja a versão impressa ou e-book.
Resultado
O ganhador foi: Rafael Oliveira
note: Um e-mail foi enviado para o ganhador o mesmo tem até 48hrs para confirmar o recebimento e dados de entrega. Caso não seja respondido em 48hrs a partir da data de envio, um novo sorteio será realizado. 
 Bom, vou ficando por aqui.
Demorou, mas chegou. 🙂
See ya!!

Java WebServices com BD

Olá Pessoal,

Dando continuidade aos post sobre webservice neste ultimo desta série, vamos ver como ter uma aplicação que faz pesquisa no banco de dados e vamos disponibilizar essa pesquisa via webservice. Um cliente nosso, vai consumir essa webservice e conseguir pesquisar em nosso banco, então deixar o “hello world” de lado. Ah, vamos usar o Hibernate framework para fazer a consultar no banco.Outro detalhe, não seguir as melhores praticas para criar  DAO genérica, fiz tudo em uma classe, o objetivo aqui não é DAO, Hibernate etc. E sim disponibilizar um web service para que possa ser consumido pelos clientes, que será uma consulta de clientes pelo ID.

Lets go…

Requisitos

  • Java 6 ou mais recente
  • MySql 5
  • Hibernate

Contexto

Se você não entendeu bem o contexto, vou dar um pouco mais de detalhe, antes de começarmos a desenvolver. Vamos ter dois projetos, um que é a nossa aplicação que pesquisa clientes por ID e o outro o projeto do fornecedor que vai consumir a webservice. O nosso banco já está populado com alguns clientes. No nosso caso serão poucos dados apenas o ID e o CPF.

Desenvolvendo

Nosso código será um pouco grande, pois vou incluir parcialmente o código do Hibernate,  também vou considerar que já conhece o framework, sendo assim, não irei explicar código que não seja relacionado webservice. Se tem dúvida com o Hibernate, pode visitar nossa categoria aqui no blog e ver o que temos por lá.  Certifique-se também que você tem uma tabela no banco populada:

A minha tabela chamei de Cliente.

Crie o projeto Java Project aqui chamei de WSDAO.

Não esqueça de adicionar os .jars do Hibernate  & MySQL ao seu projeto.

Vamos começar pelo bean, então crie uma classe cliente conforme abaixo, os getters/setters foram omitidos.

@Table

@Entity

public class Cliente {

      @Id

      @Column(name=”ID_CLIENTE”)

      @GeneratedValue

      private int id;

      @Column

      private long cpf;

//getters/setters omitidos

Agora vamos criar o nosso DAO, para isso crie uma classe conforme abaixo:

public class ClienteDAO {

            private final ThreadLocal<Session> threadLocal = new ThreadLocal<Session>();

            private final SessionFactory sessionFactory = new Configuration().configure().buildSessionFactory();

      public Session getSession(){

            Session session = threadLocal.get();

            if (session == null) {

                  session = sessionFactory.openSession();

                  threadLocal.set(session);

            }

            return session;

      }

      public Cliente getCliente(int id) {

            Session session = getSession();

            Cliente cliente = new Cliente();

            try{

                  session.beginTransaction();

            String hql = “from Cliente where id=:idvalue “;

            Query query = session.createQuery(hql );

                  query.setInteger(“idvalue”, id);

                  cliente = (Cliente) query.uniqueResult();

            }catch (HibernateException e) {

                  e.printStackTrace();

            }finally{

                  session.close();

            }

            return cliente;

      }

Criando agora o nosso SEI:

@WebService

public interface Service {

      @WebMethod

      Cliente getCliente(int id);

}

Criando SIB

@WebService(endpointInterface=”br.com.camilolopes.ws.sei.Service”)

public class ServiceImpl implements Service {

      private ClienteDAO clienteDAO = new ClienteDAO();

      @Override

      public Cliente getCliente(int id) {

            return clienteDAO.getCliente(id);

      }

}

Publicando o serviço:

public class ClientePublish {

      public static void main(String[] args) {

            Endpoint.publish(“http://localhost:9876/wscliente”, new ServiceImpl());

      }

}

Testando com SOAPUI

            Agora precisamos testar, então suba o serviço rodando a classe ClientePublish(Run → as    → Java Application ) e em seguida abra o SOAPUI, crie um projeto e passe a url do  com o wsdl (no meu caso: http://localhost:9876/wscliente?wsdl)

            Ao adicionar url certamente verá o método getCliente a esquerda na tela da esquerda da ferramenta, click no sinal + e dê dois cliques no request1. Sua tela deve ser conforme a image a seguir:

Na tag <arg0>?</arg0> vamos passar o ID do cliente que queremos buscar, então informe os Ids válidos conforme vimos mais cedo na tabela do DB. Vou informar o ID 1 e ele deve retornar o resultado na aba que está a esquerda. Troque a  ? por 1 e execute clicando no botão submit request (uma seta verde que está na parte superior da tela)

note: lembre-se que seu serviço deve tá publicado, ou seja, a classe que faz o publish deve tá rodando. No caso do exemplo do post chamei ela de ClientePublish.

O resultado é conforme a imagem a seguir:

Observe que temos o resultado no formato XML a direita. E  oque acontece se o ID  não existir? Simplesmente não traz nada. :).

Criando o Cliente para Consumir

Agora vamos criar um cliente que vai conseguir esse nosso webservice  que faz uma pesquisa no banco de dados pelo ID do cliente. Para ficar claro e separar o projeto webservice do cliente, vamos criar um projeto separado, lembrando que uma vez o serviço publicado este projeto cliente que vai consumir o webservice, não necessariamente precisa ser desenvolvido em Java, poderia ser em .NET, PHP etc.

Step 1

Crie um novo projeto Java, o do post chamei de WSDAOConsumer somente para facilitar o entendimento no post.

note: não crie os packages conforme a imagem acima, apenas o projeto por enquanto, beleza?

Step 2

            via prompt de comando acesse o src do projeto

Step 3

            import o wsdl para o projeto:

wsimport -keep -p br.ws.cliente http://localhost:9876/wscliente?wsdl

note: Se você não quiser rodar o comando wsimport verifique se a sua IDE dá suporte  na importação do wsdl de maneira visual e execute, o resultado será o mesmo. Depender da versão do Eclipse que estiver usando você terá o suporte.

Step 4

            crie em um package separado a classe que vai usar as operações do service

public class Consumer {

      public static void main(String[] args) {

            Service service = new ServiceImplService().getServiceImplPort();

                  Cliente cliente = service.getCliente(1);

                  System.out.println(cliente.getId());

                  System.out.println(cliente.getCpf());

      }

}

O resultado é mais simples possível, apenas imprime o resultado no console:

A questão é: “imprime no console, porque o meu projeto é assim, ele usa o prompt para imprimir as coisas que ele consome do web service”.Analise e pense dessa forma com o exemplo acima.Porém, Se fosse um projeto JEE eu poderia exibir isso em uma view JSF em uma tabela ou também não poderia exibir em lugar nenhum, e pegar o resultado do WS e salvar em tabela no meu banco de dados, enfim são N possibilidades que podemos fazer com os dados que estamos consumindo, isso vai está atrelado as regras de negócio do seu projeto. Resolvi trazer essa abordagem, para quem está chegando não ache que para consumir um web service deve rodar em cima de Java Application apenas.

Vou ficando por aqui, espero que vocês tenham gostado dessa  série de posts sobre web service.

Abraços, see ya!!

Throubleshooting: Tomcat Listener not found

Olá Pessoal, 

Mais um throubleshooting do dia. Não é muito difícil passar por essa quando estamos usando o eclipse. Se vc usa o maven ou adiciona as bibliotecas na mão, pode cair no contexto a seguir. Vamos ver. 

Contexto 

Tudo preparado já no seu projeto e vc resolve executar no servidor somente para ver o “hello world”. E daí, o que acontece? 

GRAVE: Error configuring application listener of class com.sun.faces.config.ConfigureListener

java.lang.ClassNotFoundException: com.sun.faces.config.ConfigureListener 

 

Mas qual o motivo? 

Simples! Mesmo vc adicionando as dependências de lib ao seu projeto, quando vc faz um deploy o tomcat busca as libs na pasta lib do projeto, isso é o correto, certo? Mas o Eclipse não copia os arquivos automaticamente para o lib. E o tomcat, ao chegar lá não vai achar aquelas libs externas que precisa, como a do JSF, primefaces, richfaces etc. No caso dos componentes JSF, ele apenas não é exibido no browser, mas a do JSF por exemplo, ele da error 404 not found.

Solução

Essa é difícil. Copiar os .jars  para a pasta lib do projeto e pronto. Você pode fazer essa cópia automática, dizendo ao maven para colocar as libs já no diretório lib do projeto. Daí é só ver na documentação. 

Abracos, vou ficando por aqui. Espero que estejam curtindo os posts de thoubleshooting.

See ya!!