Ae pessoal, como a algum tempo ja nao moro mais no Brasil, e tenho alguns colegas de trabalho que usam o meu blog como alguma referencia porem usam o Google Translator, entao daqui para frente todos os post's irao ser em ingles.
O novo endereco e : http://klausvillaca-en.blogspot.com/
Obrigado a todos que me mandaram email, porem escrever em ingles e uma necessidade para mim agora.
Abracos
Klaus Villaca
Monday 13 September 2010
Sunday 23 May 2010
RUP Classico, e problemas com os ultimos projetos
Prefacio :
Desde que deixei o pais onde eu utilizava Metodologia Agil (Agile Methodology), estou sendo obrigado a trabalhar com o RUP Classico e acredite nao e facil, sei que muita gente nao consegue acreditar que ser Agil e possivel com projetos maiores e mesmo grandes, tambem muitos tem dificuldade ou simplemsnte nao conseguem idealizar um projeto sem o Ghant Chart do MS Project ou similares. Eles colocam um monte de impecilhos bem classicos de pessoas que somente conhecem uma metodologia ou uma parte de uma cidade e falam que a outra parte nao presta, mesmo sem conhecer, ou seja eles passaram a vida toda fazendo somente uma coisa nesse caso o RUP e infelizmente perderam a criatividade e imaginacao em como resolver as coisas de modos diferentes, mas continuam a achar que aquela verdade deles e a absoluta e imutavel.
Uma coisa que acho muito interessante em trabalhar como Arquiteto e Desenvolvedor e que isso tudo tem muito a ver com a vida em si. E como voce planeja tirar uma certificacao, ou comprar um carro ou mesmo atingir um objetivo, voce pensa em varias maneiras possiveis, claro que existe os Patterns para cada coisa da vida bem como para cada coisa em projetos de TI, mas prefasiando… existe varias maneiras de se partir do ponto A e chegar ao ponto B. Na verdade existe milhares de possibilidades de se fazer isso, tem pessoas que esmeram fazer o melhor que eles podem ate o momento, digo ate o momento pq esse tipo de pessoa sao os autoditadas, e parae les perfeicao e um estado que somente existe no nirvana, eles estao sempre aprimorando, e aprendendo novas coisas, e se voce quer saber sao eles a roda que move o mundo. Depois temos a classe das pessoas normais que somente aprendem alguma coisa via cursos e faculdades e ficam naquilo por anos, e por fim aquele cara que entrou nessa so para ganhar dinheiro, e infelizmente hoje em TI temos rios de pessoas assim, pior alguns em cargos de gerencia e como Gerentes de Projetos. Sao pessoas que estudam muito, na visao deles, pq em TI nunca estudar e muito, pois passamos a vida inteira como um fisico somente estudando e aprendendo, e depois eles passam em uma entrevista de emprego e e ai que os problemas comecam para todos aqueles que estao embaixo dele. Nao sei se voce que esta lendo isso sabe mas o RUP - Rational Unified Process foi criado pela antiga Rational hoje IBM para a Boeing para melhorar a linha de producao dequela fabrica de avioes nos anos 50!
Agora vamos fazer uma comparacao bem rapida… Linha de montagem de avioes dos anos 50 com producao de software no seculo 21!!! Alguem ai consegue ver algo que se conecta?????
Bom repetindo o que vem sendo dito e repetido a tempos “Software nao e como fazer pontes, onde voce na verdade faz somente uma e todas as outras sao copias dela, software e um processo dinamico, criativo e sempre ira ser diferente”
Eu ate hoje com quase 20 anos de TI nunca vi um projeto se igual ao outro, ja vi similares, mas igual nunca, tambem nunca vi, nem a aquipe de desenvolvimento e nem os Gerentes de Projeto lendo documentacao antiga ou mesmo se baseando em projetos antigos para se crier um novo. ISSO NAO EXISTE!
Portando se nao deveria mais existir isso em desenvolvimento de software.
Indo para o que interessa :
Aqui agora vou citar e dar exemplos dos maiores problemas por que meu time passou usando RUP Classico.
Primeira e do meu ponto de vista e um dos mais cruciais pontos, e que ninguem tem um dominio complete nem conhecimento completo do sistema, ou seja muito das integracoes sao feitas na base do bom senso e em suposicoes, isso e terrivel para qualquer area, ja pensou um engenheiro civil ter que contruir aquela ponte do comeco baseado em suposicoes e bom senso o que iria acontecer?
Depois vem a qualidade das informacoes, visto que nao temos contato com o Analista de Sistemas e somente alguns com os famosos Analistas de Negocios, as especificacoes vem muitas vezes com falhas de logica no processo graves e ninguem sabe como resolver isso, e mais uma vez temos que usar bom senso e suposicoes para resolver isso.
Os desenvolvedores tem que fazer a revisao das especificacoes que sao atribuidas pelo GP, como e possivel um pessoa que nao tem ideia do que esta acontecendo fazer revisao de uma especificacao, que pode conter falhas graves, e apontar erros?
E o ultimo dos piores e as constants novas versoes que eles ficam produzindo das especificacoes, ou seja constants mudancas no codigo tambem.
Agora olhando o RUP que tem 4 fases distintas que sao : Concepcao, Elaboracao, Construcao e Transicao.
Nao e preciso nem ter mais um nivel de profundidade em cada uma dessas para ver que isso nao funciona.
Concepcao : Comecando com uma pergunta. Para que concepcao? Qual o objetivo de ser ter uma vaga ideia do que se quer? Somente para amadurecer depois? Desde que o mundo e mundo qdo vc procura uma solucao e pq vc ja tem um problema certo! Entao concepcao e uma fase que deve ser boa para engenheiros civil, aeronautico e outros afim, que nao precisa fazer uma analise para ter comecar a conceber alguma coisa, ele que recebe um requerimento para algo. Ex: Aviao X, devera levar 2 pilotos, atingir velocidade de Mach 2.5 sem pos combustores, ter um teto absolute de 100.000 pes,velocidade ascencional de 18.000mts/min. , ter uma carga de armas de 20ton., ter um radar com capacidade de descoberta entre 60mts a 25km the altura, rastrear 20 alvos simultaneamente, e ter um raio de acao de 2500km.
Ai sim e valido essa ideia de concepcao, mas para software, e diferente, pq primeiro vamos ver como os processos sao feitos, levantar o que pode ser otimizado e informatizado, depois olhar a fundo em todos os processos e como funcionam, o que nao tem nada a ver com concepcao e sim com Analise, que ja devera ser a proxima etapa.
Elaboracao: E aqui que no RUP o projeto vai comecar a tomar forma. Mais uma pergunta tomar forma? Voces conhecem algum analista de sistmas que te da alguma forma de um sistema? Isso e tao furado que ate se vc procurar no Wiki (http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process), vc ira ver essa palavra forma la. Nao exister dar forma e ver possiveis erros do sistema, o que existe e o analista ir fazer os levantamentos dos requisitos e problemas que sao enfrentados atualmente e depois prover uma solucao para esses problemas usando uma solucao informatizada ou nao. Me desculpem, mas eu nao consigo ver nenhuma forma de sistema ate aqui. Mais ainda, para que o sistema seja coerente e bem escrito e fundamental que o analista participe ativamente do desenvolvimento, e tenha bons conhecimentos do que ira ser usado no sistema, como linguagem, frameworks e etc, pois com isso ele epode fazer uma analise voltada para os pontos fortes de cada um desses items que serao usados, e ja prover como contornar e resolver problemas decorrentes dos pontos fracos desses items. E isso acreditem faz toda a diferenca entre um sistema que ira dar um bom ROI e o que nao vai.
Mais uma pergunta ue nunca tem resposta. Como e possivel um analista que nao sabe para o que ele esta elaborando isso, nem que linguagem ou ferramentas irao ser usadas, nem o nivel do time que vai trabalhar, passar tudo que ele viu e imaginou e as solucoes que ele esta propondo, por escrito, para um time que vai tentar resumir, preste atencao e isso mesmo resumir, o que ja deveria ser um resumo ed como a empresa trabalha. Como ira ser possivel que todas as informacoes pertinentes irao de fato estar la? Nao e possivel, a nao ser que eles passem a analise inteira como especificacao, pior, o que acontece muito e que eles dividem as tarefas de um processo maior sem lever em conta que muita coisa esta interconectada. E ai muito se perde dos processos e eles ficam imcompletos e mais, precisando de uma manutencao assim que o projeto termina. O que e ridiculo. Ja pensou assim que vc inaugural ponto, vc a fecha para refazer algumas partes pq nao era bem isso o que a prefeitura precisava?
Construcao: E aquii que a lambanca comeca, sem contato com o analista e com um resumo do resumo em mao mais, diga se menos ne, um suporte para duvidas que se baseia somente no que esta escrito e nada mais, como e que voce pode criar uma boa arquitetura de projeto e mesmo codigo coerente com o que realmente ira ser necessario para que se resolva aquele problema do inicio? Como voce vai interconectar as partes que for a separadas, sem criar redundante codigo, e muitos copy and paste? Melhor como voce pode criar uma arquitetura baseando somente em resumos do resumo e ainda por cima com somente uma parte do sistema que ira ser feito passado a voce? Em 100% dos casos se voce quizer fazer algo no minimo descente ira ser preciso um conhecimento mais amplo par aver o que podera ser reaproveitado, que patterns usar, ou criar. Vendo isso, e bem dificil voce ter alta coesao e baixo acoplamento. O que o codigo faz e o reflexo do que foi passado ao time de arquiteto e desenvolvedores, se foi passado partes voce somente pode aprimorar partes, que nao que dizer que irao ser bem e irao corresponder com as espectativas de solucao requeridas na primeira fase. O mais legal e os testes serem aplicados com base nessa documentacao… ou seja muito do que realmente deveria ser testado nao e.
Transicao: Isso e com a parte do pessoal de producao, e eles reclamam bastante, que o codigo nao tem o merge com as outras partes que eles esperam e isso tb toma muito tempo ate que eles tenham o fine tuning.
Claro que ha muito mais problemas que isso, e tambem ira aparecer pessoas que vao falar algo mais ou menos assim “ahhh!! Mas sua emrpesa nao implementou isso ou aquilo e eram fundamental para que seu projeto tivesse sucesso”. Para essas pessoas que pensam de modo similar ou igual e facil resolver isso para provar que RUP nao funciona. Se coloque na posicao do dono da empresa e veja o ROI e a solucao entregue usando RUP e AGILE… garanto que a segunda vai ser mais rapida, barata e ira agregar muito mais a sua empresa do que a primeira, fora que a segunda vai ser a que mais vai se parecer com o que vc tinha em mente do que a primeira.
Nao estou falando que a IBM ou seus produtos nao prestam, pelo contrario, eles tem excelentes produtos e servicos, mas sendo especifico com a metodologia e a producao de software, o RUP nao funciona. Porem e muito bom para o ROI da mesma, pois com isso eles vendem mais ferramentas que na verdade nao agregam muito a producao de software em si e mais como meios de ‘controles’ para as terefas que cada professional em cada etapa usa , recebem por contratos mais longos, suporte e ainda vendem cursos para treinar essas pessoas para aquelas ferramentas. E um Mercado todo novo e rentavel.
Tambem vale frisar que Agile nao e a solucao unica para todos projetos do mundo, pois certos times que nao possuem o feeling, organizacao ou mesmo o nivel de conhecimento necessario para a tarefa nao irao conseguir entregar algo de qualidade.
Com isso finaliso contando problemas que enfrentei quanto a metodologia e o que acarretou para o desenvolvimento. O que acho mais incrivel e que este e meu terceiro projeto aqui, usando a mesma metodologia no terceiro lugar diferente, e todos carecem dos mesmo problemas em maior ou menor grau.
Por fim vale lembrar aqui que RUP e muito bom para pessoas limitadas e nao para os autodidatas, pq com isso eles se sentem bem com o pouco que sabem, nao precisam ficar correndo atras para aprender mais, pq eles estao trabalhando como maquinas mal programadas e faz com que eles tenham orgulho em dizer que so sabem fazer isso ou aquilo, qdo o certo seria que eles tivessem orgulho em dizer, hoje estou fazendo isso, mas amanha aquilo e depois quem sabe, pois estou crescendo como pessoa e como profissional. Quando forem implementer um codigo, um projeto ou mesmo projetos de vida lembrem-se que ha milhares de maneiras diferentes de se chegar la, umas melhores outras nao tao boas, porem muito vai depender da situacao naquele momento e na sua visao para o futuro.
Desde que deixei o pais onde eu utilizava Metodologia Agil (Agile Methodology), estou sendo obrigado a trabalhar com o RUP Classico e acredite nao e facil, sei que muita gente nao consegue acreditar que ser Agil e possivel com projetos maiores e mesmo grandes, tambem muitos tem dificuldade ou simplemsnte nao conseguem idealizar um projeto sem o Ghant Chart do MS Project ou similares. Eles colocam um monte de impecilhos bem classicos de pessoas que somente conhecem uma metodologia ou uma parte de uma cidade e falam que a outra parte nao presta, mesmo sem conhecer, ou seja eles passaram a vida toda fazendo somente uma coisa nesse caso o RUP e infelizmente perderam a criatividade e imaginacao em como resolver as coisas de modos diferentes, mas continuam a achar que aquela verdade deles e a absoluta e imutavel.
Uma coisa que acho muito interessante em trabalhar como Arquiteto e Desenvolvedor e que isso tudo tem muito a ver com a vida em si. E como voce planeja tirar uma certificacao, ou comprar um carro ou mesmo atingir um objetivo, voce pensa em varias maneiras possiveis, claro que existe os Patterns para cada coisa da vida bem como para cada coisa em projetos de TI, mas prefasiando… existe varias maneiras de se partir do ponto A e chegar ao ponto B. Na verdade existe milhares de possibilidades de se fazer isso, tem pessoas que esmeram fazer o melhor que eles podem ate o momento, digo ate o momento pq esse tipo de pessoa sao os autoditadas, e parae les perfeicao e um estado que somente existe no nirvana, eles estao sempre aprimorando, e aprendendo novas coisas, e se voce quer saber sao eles a roda que move o mundo. Depois temos a classe das pessoas normais que somente aprendem alguma coisa via cursos e faculdades e ficam naquilo por anos, e por fim aquele cara que entrou nessa so para ganhar dinheiro, e infelizmente hoje em TI temos rios de pessoas assim, pior alguns em cargos de gerencia e como Gerentes de Projetos. Sao pessoas que estudam muito, na visao deles, pq em TI nunca estudar e muito, pois passamos a vida inteira como um fisico somente estudando e aprendendo, e depois eles passam em uma entrevista de emprego e e ai que os problemas comecam para todos aqueles que estao embaixo dele. Nao sei se voce que esta lendo isso sabe mas o RUP - Rational Unified Process foi criado pela antiga Rational hoje IBM para a Boeing para melhorar a linha de producao dequela fabrica de avioes nos anos 50!
Agora vamos fazer uma comparacao bem rapida… Linha de montagem de avioes dos anos 50 com producao de software no seculo 21!!! Alguem ai consegue ver algo que se conecta?????
Bom repetindo o que vem sendo dito e repetido a tempos “Software nao e como fazer pontes, onde voce na verdade faz somente uma e todas as outras sao copias dela, software e um processo dinamico, criativo e sempre ira ser diferente”
Eu ate hoje com quase 20 anos de TI nunca vi um projeto se igual ao outro, ja vi similares, mas igual nunca, tambem nunca vi, nem a aquipe de desenvolvimento e nem os Gerentes de Projeto lendo documentacao antiga ou mesmo se baseando em projetos antigos para se crier um novo. ISSO NAO EXISTE!
Portando se nao deveria mais existir isso em desenvolvimento de software.
Indo para o que interessa :
Aqui agora vou citar e dar exemplos dos maiores problemas por que meu time passou usando RUP Classico.
Primeira e do meu ponto de vista e um dos mais cruciais pontos, e que ninguem tem um dominio complete nem conhecimento completo do sistema, ou seja muito das integracoes sao feitas na base do bom senso e em suposicoes, isso e terrivel para qualquer area, ja pensou um engenheiro civil ter que contruir aquela ponte do comeco baseado em suposicoes e bom senso o que iria acontecer?
Depois vem a qualidade das informacoes, visto que nao temos contato com o Analista de Sistemas e somente alguns com os famosos Analistas de Negocios, as especificacoes vem muitas vezes com falhas de logica no processo graves e ninguem sabe como resolver isso, e mais uma vez temos que usar bom senso e suposicoes para resolver isso.
Os desenvolvedores tem que fazer a revisao das especificacoes que sao atribuidas pelo GP, como e possivel um pessoa que nao tem ideia do que esta acontecendo fazer revisao de uma especificacao, que pode conter falhas graves, e apontar erros?
E o ultimo dos piores e as constants novas versoes que eles ficam produzindo das especificacoes, ou seja constants mudancas no codigo tambem.
Agora olhando o RUP que tem 4 fases distintas que sao : Concepcao, Elaboracao, Construcao e Transicao.
Nao e preciso nem ter mais um nivel de profundidade em cada uma dessas para ver que isso nao funciona.
Concepcao : Comecando com uma pergunta. Para que concepcao? Qual o objetivo de ser ter uma vaga ideia do que se quer? Somente para amadurecer depois? Desde que o mundo e mundo qdo vc procura uma solucao e pq vc ja tem um problema certo! Entao concepcao e uma fase que deve ser boa para engenheiros civil, aeronautico e outros afim, que nao precisa fazer uma analise para ter comecar a conceber alguma coisa, ele que recebe um requerimento para algo. Ex: Aviao X, devera levar 2 pilotos, atingir velocidade de Mach 2.5 sem pos combustores, ter um teto absolute de 100.000 pes,velocidade ascencional de 18.000mts/min. , ter uma carga de armas de 20ton., ter um radar com capacidade de descoberta entre 60mts a 25km the altura, rastrear 20 alvos simultaneamente, e ter um raio de acao de 2500km.
Ai sim e valido essa ideia de concepcao, mas para software, e diferente, pq primeiro vamos ver como os processos sao feitos, levantar o que pode ser otimizado e informatizado, depois olhar a fundo em todos os processos e como funcionam, o que nao tem nada a ver com concepcao e sim com Analise, que ja devera ser a proxima etapa.
Elaboracao: E aqui que no RUP o projeto vai comecar a tomar forma. Mais uma pergunta tomar forma? Voces conhecem algum analista de sistmas que te da alguma forma de um sistema? Isso e tao furado que ate se vc procurar no Wiki (http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process), vc ira ver essa palavra forma la. Nao exister dar forma e ver possiveis erros do sistema, o que existe e o analista ir fazer os levantamentos dos requisitos e problemas que sao enfrentados atualmente e depois prover uma solucao para esses problemas usando uma solucao informatizada ou nao. Me desculpem, mas eu nao consigo ver nenhuma forma de sistema ate aqui. Mais ainda, para que o sistema seja coerente e bem escrito e fundamental que o analista participe ativamente do desenvolvimento, e tenha bons conhecimentos do que ira ser usado no sistema, como linguagem, frameworks e etc, pois com isso ele epode fazer uma analise voltada para os pontos fortes de cada um desses items que serao usados, e ja prover como contornar e resolver problemas decorrentes dos pontos fracos desses items. E isso acreditem faz toda a diferenca entre um sistema que ira dar um bom ROI e o que nao vai.
Mais uma pergunta ue nunca tem resposta. Como e possivel um analista que nao sabe para o que ele esta elaborando isso, nem que linguagem ou ferramentas irao ser usadas, nem o nivel do time que vai trabalhar, passar tudo que ele viu e imaginou e as solucoes que ele esta propondo, por escrito, para um time que vai tentar resumir, preste atencao e isso mesmo resumir, o que ja deveria ser um resumo ed como a empresa trabalha. Como ira ser possivel que todas as informacoes pertinentes irao de fato estar la? Nao e possivel, a nao ser que eles passem a analise inteira como especificacao, pior, o que acontece muito e que eles dividem as tarefas de um processo maior sem lever em conta que muita coisa esta interconectada. E ai muito se perde dos processos e eles ficam imcompletos e mais, precisando de uma manutencao assim que o projeto termina. O que e ridiculo. Ja pensou assim que vc inaugural ponto, vc a fecha para refazer algumas partes pq nao era bem isso o que a prefeitura precisava?
Construcao: E aquii que a lambanca comeca, sem contato com o analista e com um resumo do resumo em mao mais, diga se menos ne, um suporte para duvidas que se baseia somente no que esta escrito e nada mais, como e que voce pode criar uma boa arquitetura de projeto e mesmo codigo coerente com o que realmente ira ser necessario para que se resolva aquele problema do inicio? Como voce vai interconectar as partes que for a separadas, sem criar redundante codigo, e muitos copy and paste? Melhor como voce pode criar uma arquitetura baseando somente em resumos do resumo e ainda por cima com somente uma parte do sistema que ira ser feito passado a voce? Em 100% dos casos se voce quizer fazer algo no minimo descente ira ser preciso um conhecimento mais amplo par aver o que podera ser reaproveitado, que patterns usar, ou criar. Vendo isso, e bem dificil voce ter alta coesao e baixo acoplamento. O que o codigo faz e o reflexo do que foi passado ao time de arquiteto e desenvolvedores, se foi passado partes voce somente pode aprimorar partes, que nao que dizer que irao ser bem e irao corresponder com as espectativas de solucao requeridas na primeira fase. O mais legal e os testes serem aplicados com base nessa documentacao… ou seja muito do que realmente deveria ser testado nao e.
Transicao: Isso e com a parte do pessoal de producao, e eles reclamam bastante, que o codigo nao tem o merge com as outras partes que eles esperam e isso tb toma muito tempo ate que eles tenham o fine tuning.
Claro que ha muito mais problemas que isso, e tambem ira aparecer pessoas que vao falar algo mais ou menos assim “ahhh!! Mas sua emrpesa nao implementou isso ou aquilo e eram fundamental para que seu projeto tivesse sucesso”. Para essas pessoas que pensam de modo similar ou igual e facil resolver isso para provar que RUP nao funciona. Se coloque na posicao do dono da empresa e veja o ROI e a solucao entregue usando RUP e AGILE… garanto que a segunda vai ser mais rapida, barata e ira agregar muito mais a sua empresa do que a primeira, fora que a segunda vai ser a que mais vai se parecer com o que vc tinha em mente do que a primeira.
Nao estou falando que a IBM ou seus produtos nao prestam, pelo contrario, eles tem excelentes produtos e servicos, mas sendo especifico com a metodologia e a producao de software, o RUP nao funciona. Porem e muito bom para o ROI da mesma, pois com isso eles vendem mais ferramentas que na verdade nao agregam muito a producao de software em si e mais como meios de ‘controles’ para as terefas que cada professional em cada etapa usa , recebem por contratos mais longos, suporte e ainda vendem cursos para treinar essas pessoas para aquelas ferramentas. E um Mercado todo novo e rentavel.
Tambem vale frisar que Agile nao e a solucao unica para todos projetos do mundo, pois certos times que nao possuem o feeling, organizacao ou mesmo o nivel de conhecimento necessario para a tarefa nao irao conseguir entregar algo de qualidade.
Com isso finaliso contando problemas que enfrentei quanto a metodologia e o que acarretou para o desenvolvimento. O que acho mais incrivel e que este e meu terceiro projeto aqui, usando a mesma metodologia no terceiro lugar diferente, e todos carecem dos mesmo problemas em maior ou menor grau.
Por fim vale lembrar aqui que RUP e muito bom para pessoas limitadas e nao para os autodidatas, pq com isso eles se sentem bem com o pouco que sabem, nao precisam ficar correndo atras para aprender mais, pq eles estao trabalhando como maquinas mal programadas e faz com que eles tenham orgulho em dizer que so sabem fazer isso ou aquilo, qdo o certo seria que eles tivessem orgulho em dizer, hoje estou fazendo isso, mas amanha aquilo e depois quem sabe, pois estou crescendo como pessoa e como profissional. Quando forem implementer um codigo, um projeto ou mesmo projetos de vida lembrem-se que ha milhares de maneiras diferentes de se chegar la, umas melhores outras nao tao boas, porem muito vai depender da situacao naquele momento e na sua visao para o futuro.
Monday 5 April 2010
Java e ainda e uma linguagem de futuro garantido ???
Ola hoje vou falar um pouco sobre se o Java ainda e uma linguagem de futuro, vou tentar expor os pro e os contras e MINHA opniao, mas isso NAO quer dizer que e a VERDADE, cada uma vai tirar suas proprias conclusoes, ok. O objetivo disso nao e por lenha na fogueira entre .Net e Java de jeito nenhum. E somente mesmo pros e contras.
Vamos la
Antes de tudo, curto Java mas nao sou aquele fanatico, tenho mais de 20 anos de experiencia trabalhando com sistemas, ja morei for a do pais a trabalho e atualmente estou na Australia, ja fiz sistemas em Basic (NX-80, TRS80, CP/M, Quick Basic e outras versoes), C (em Mainframes, superminis Cobra e Scopus, lembram..., e sistemas DOS/Windows 3.11/95/98/XP), C++ (Windows 3.11, OS/2 um tipo de Unix da IBM), COBOL (para os mesmos tipos de maquinas que fiz usando C), Datafles, Progress e Visual Basic desde a versao 4 ate a 6, FoxPro desde a versao 2.0 ate as ultimas, e por fim Java que venho usando a anos (em todos ambientes que existe uma JVM rodando, do Windows ao OS/390 da IBM).
Gosto muito de ver que os desenvolvedores Java sao bem fieis a tudo que e relacionado ao Java porem muitos carecem de um feeling para ver que existe muita coisa boa la for a tb, e que Java nao e maior maravilha em linguagens de programacao, mas o q me irrita e que muitos querem por todos os patterns e EJB que eles conhecem em um sistema de pequeno. E aquela velha comparacao “Qdo voce tem uma martelo como unica ferramenta, todos os seus problemas se parecem com pregos”. Acho que nao preciso dizer mais.
Java saiu em 1995 como uma linguagem de Scripts, e evoluiu para um linguagem completa, nao e a famosa bala de prata das linguagens mas chegou bem proximo, e ao meu ver foi por ter tantos ramos que ela esta falhando. Com a compra pela Oracle as coisas deverao comecar a mudar o ano que vem, pois ainda e muito cedo para se ter uma ideia do que ira acontecer, pois tudo sera expeculacao. Porem se tem muito indicios que algumas coisas irao mudar com quase certeza.
Apos alguns anos trabalhando com Java pude constatar que, Swing nao e um ambiente ideal para desktop, e pesado com um visual ultrapassado e consome muita memoria, e nao teve grandes melhorias nas ultimas versoes do Java, ate teve, mas nada que realmente chamasse a atencao, por isso vejo com muita frequencia o .Net dominar nessa area, por varios fatores que vou falar ja ja.
Swing e a aposta da Sun, agora Oracle, pois nao sei se vai dar muita enfase nessa area daqui para frente em atualizar e melhorar essa “area” do universo Java, contra a SWT que mesmo nao sendo tao portavel e muito melhor que Swing, quem nao gostar que faca a comparacao e nao precisa ir longe, e so olhar o Eclipse e o NetBeans e ver a velocidade que cada um roda e o visual de cada um.
Entao para desktop applications Swing nao vale a pena, a nao ser que voce seja um bitolado em tudo que vinha da Sun (Oracle). Hoje temos varias linguagem que podem fazer sistemas para desktop com muito mais recursos do que Java Swing.
Como nao tenho mais desenvolvido sistemas para Swing a anos e somente fuçado, sao essas minhas conclusoes a respeito do Swing.
Java ME / Java FX, ao meu ver tinha tudo para dar certo, mas a JVM muito grande e pesada inviabilizou tudo, e a falha da Sun em produzir uma versao light para a mobiles fez com que muitas companhias nao dessem suporte para a mesma, a Apple e uma caso a parte, quer ser diferente, elitizada para faturar mais, basicamente falando. Mas a maior falha da Sun foi lancar o FX que deu um tiro no proprio pe, afinal colocou um produto muito similar ao ME com mais recursos visuais e todos que apostaram no ME se sentiram traidos com o FX pq se precisava de atualizacoes nas JVM para rodar o FX. Depois a Sun quiz colocar o FX como um concorrente do Flash e do Silverlight da MS que tambem nao enquadrou, a base ate hoje e minuscula de desenvolvedores e agora com a Oracle talvez nunca mais vai chegar la.
Java EE, aqui sim e o nicho do Java, e onde ele e forte e onde nas ultimas versoes teve as melhores melhorias, chamar atualmente o programador Java de futuro “COBOL guy” nao esta errado pois e o que ja esta acontecendo, vejo ainda muitos novos projetos sendo desenvolvidos em Java mas 95% deles para Web, e principalmente para Server side, ocupando o lugar de muitos sistemas que eram feitos em COBOL, muitas vezes. Sim nessa area nao se tem uma linguagem com tantos frameworks como Java. Struts e JSF 1.2 hoje sao os dominantes e deverao ficar por muito anos ainda, afinal empresas que gastam milhoes para criar um sistema nao vao trocar apos alguns anos somente pq um novo e melhor framework veio, eles sao vao trocar se trocar quando realmente nao tiver mais jeito, e ao meu ver eles estao certos, pois os sistemas adquiridos por elas sao mais uma engrenagem na maquina de fazer dinheiro.
Essa e a area em que o Java bate qualquer linguagem por uma larga margem, afinal e a unica lingugagem que e plataforma independente para servidores e possue muitos recursos mesmo para quem nao que mais usar EJB, existe muita coisa boa por ae, e por sinal muitas muito boas e de graca, sendo ao meu ver o Spring a melhor de todas e se voce tiver conhecimento suficiente de EJBs e Spring voce nao precisa de mais nada afinal os dois tem pontos muito fortes que podem ser aproveitados e bem. Em server side nada bate o java hoje e nao devera bater por muitos anos.
Agora no lado do cliente a coisa muda de figura, com as novas linguagens baseadas na JVM e mesmo Flash, Silverlight, PHP, ASP e outras muitas delas hoje tem muitos mais recursos para se desenvolver um Rich Client do que as tecnologias Java propriamente ditas, como JSF, Struts, Tapestry, JSP e por ai vai. Claro que se tivessemos IDEs com melhores suportes para a parte visual ajudaria em muito o desenvolvimento dessas, se voce acha que o Eclipse e NetBeans sao otimos, voce deveria dar uma olhada na IDE do .Net, que voce ira mudar radicalmente de ideia e bem rapido. Ja vi uns malucos fazendo sistemas para bancos em .Net para rodar me server side, e me garantiram que estava sendo uma tarefa herculea, devido a falta de recursos para o mesmo e muitos deles me falaram se fosse em Java estariam longe e com muito mais seguranca, o que acredito mesmo.
E ja vi muito tambem de programadores Java reclamando que para trabalhar com client side usando Java nao e tao facil qto usando algumas dessas linguagens que citei aqui em cima, principalemente se falando em manutencao, afinal 90% da vida de um sistema e manutencao e somente 10% e a concepcao do mesmo.
Agora a pergunta Java vai estar no meio de nos por muitos anos ainda ?
SIM definitivamente vai por muitos anos ainda, mas no seu nicho, nao consigo visualizar grandes projetos usando Java para o lado do cliente, tambem nao vi grandes melhorias no Java SE 7, e algumas boas no EE 6 (JSF 2.0 e EJB 3.1 sao as melhores). Tambem nao vejo muito mais o que “inventar” para colocar dentro do pacote, nao acredito tambem que a Oracle vai se empenhar tanto qto a Sun em prover um Java tao update e de graca, o que esta parecendo e que vai acontecer e uma ruptura e nao estar muito longe de acontecer, pois de um lado temos a Oracle que comprou a Sun recentemente e ainda ta pondo a casa no lugar, no outro temos a IBM que e a maior desenvolvedora de Java do mundo e ambas competem em muitas areas. E facil de ver que muitas das novas implementacoes do Java serao pagas e que a IBM nao vai deixar barato, se isso acontecer, e vai implementar suas necessidades na JVM logo em seguida. E com isso logo logo iremos ter duas JVMs, muito similares mas nao 100% compativeis.
Agora se voce quer um conselho em que linguagem comecar te dou tres escolhas e as tres sao OTIMAS, mas em primeiro lugar de todas para se aprender e a linguagem C, depois Java e .Net
E so ver que C roda em OS/390, Unix, Linux e Windows como Java, e .Net por causa do grande numero de plataformas Windows existente. Claro que ha as discrepancias, entre as plataformas, mas muito do codigo do C pode rodar em outras plataformas sendo somente recompilados na mesma.
O que esta faltau para o Java deslanchar nas outras areas que mencionei aqui, ao meu ver, foram uma JVM mais rapida e compacta, um JCP program mais eficaz e rapido ou quem sabe mesmo um gerador de codigo nativo, que vai contra a premissa da JVM mas que daria muito mais velocidade ao Java, ou mesmo um hardware da JVM que pudesse ter updates para ter as novas implementacoes ou mesmo algo hbrido, como algumas funcoes que nao se muda tanto da JVM em um processador, que pudesse ser setada na JVM ne, e outras ele usaria da JVM software. Acho que essa ansia por ter mais Java classes a cada versao nao foi e nao e saudavel para o Java em si, retrocompatibilidade e bom, mas ate um certo ponto, uma hora ira ter que haver uma ruptura para que se tenha algo com mais qualidade e melhor e que isso venha logo antes que seja tarde demais.
Hoje o Java ainda esta no embalo provido pela Sun no passado, mas logo logo isso vai passar se a Oracle nao se mobilizar e muito rapido. Se a Oracle realmente fazer a licao de casa e correr atras sim o Java podera se eternizar como linguagem, mas se nao, os programadores Java de hoje se tornacao os Coboleros de hoje no futuro.
Acho sim que Java e uma linguagem bem verbose, mas acho isso muito saudavel tb, afinal quem nunca teve problemas com aqueles milhares de processos invisiveis acontecendo por de tras dos bastidores sem que vc saiba, e que te tras um resultado que voce nao quer? E isso e um dos segredos do sucesso do Java sobre as outras linguagens, esse negocio de um comando ou classe fazer um mundo e utopico e ate a MS viu isso, por isso acho que isso e uma das forcas do Java tambem. Vale lembrar que o mercado de linguagens vale bilhoes hoje e que a MS NAO dorme no ponto.
Bom dei um cobrida bem superficial mesmo sobre o que se tem do Java e o que nao se tem uma olhada tb muito superficial nas especulacoes sobre o futuro do Java.
Por favor se voce tiver alguma duvida, nao gostar ou mesmo se falei alguma besteira aqui e so falar que posso corrigir, afinal como disse minha palavra nao e final. Mas por favor nao venha com grosserias ok.
Abs.
Vamos la
Antes de tudo, curto Java mas nao sou aquele fanatico, tenho mais de 20 anos de experiencia trabalhando com sistemas, ja morei for a do pais a trabalho e atualmente estou na Australia, ja fiz sistemas em Basic (NX-80, TRS80, CP/M, Quick Basic e outras versoes), C (em Mainframes, superminis Cobra e Scopus, lembram..., e sistemas DOS/Windows 3.11/95/98/XP), C++ (Windows 3.11, OS/2 um tipo de Unix da IBM), COBOL (para os mesmos tipos de maquinas que fiz usando C), Datafles, Progress e Visual Basic desde a versao 4 ate a 6, FoxPro desde a versao 2.0 ate as ultimas, e por fim Java que venho usando a anos (em todos ambientes que existe uma JVM rodando, do Windows ao OS/390 da IBM).
Gosto muito de ver que os desenvolvedores Java sao bem fieis a tudo que e relacionado ao Java porem muitos carecem de um feeling para ver que existe muita coisa boa la for a tb, e que Java nao e maior maravilha em linguagens de programacao, mas o q me irrita e que muitos querem por todos os patterns e EJB que eles conhecem em um sistema de pequeno. E aquela velha comparacao “Qdo voce tem uma martelo como unica ferramenta, todos os seus problemas se parecem com pregos”. Acho que nao preciso dizer mais.
Java saiu em 1995 como uma linguagem de Scripts, e evoluiu para um linguagem completa, nao e a famosa bala de prata das linguagens mas chegou bem proximo, e ao meu ver foi por ter tantos ramos que ela esta falhando. Com a compra pela Oracle as coisas deverao comecar a mudar o ano que vem, pois ainda e muito cedo para se ter uma ideia do que ira acontecer, pois tudo sera expeculacao. Porem se tem muito indicios que algumas coisas irao mudar com quase certeza.
Apos alguns anos trabalhando com Java pude constatar que, Swing nao e um ambiente ideal para desktop, e pesado com um visual ultrapassado e consome muita memoria, e nao teve grandes melhorias nas ultimas versoes do Java, ate teve, mas nada que realmente chamasse a atencao, por isso vejo com muita frequencia o .Net dominar nessa area, por varios fatores que vou falar ja ja.
Swing e a aposta da Sun, agora Oracle, pois nao sei se vai dar muita enfase nessa area daqui para frente em atualizar e melhorar essa “area” do universo Java, contra a SWT que mesmo nao sendo tao portavel e muito melhor que Swing, quem nao gostar que faca a comparacao e nao precisa ir longe, e so olhar o Eclipse e o NetBeans e ver a velocidade que cada um roda e o visual de cada um.
Entao para desktop applications Swing nao vale a pena, a nao ser que voce seja um bitolado em tudo que vinha da Sun (Oracle). Hoje temos varias linguagem que podem fazer sistemas para desktop com muito mais recursos do que Java Swing.
Como nao tenho mais desenvolvido sistemas para Swing a anos e somente fuçado, sao essas minhas conclusoes a respeito do Swing.
Java ME / Java FX, ao meu ver tinha tudo para dar certo, mas a JVM muito grande e pesada inviabilizou tudo, e a falha da Sun em produzir uma versao light para a mobiles fez com que muitas companhias nao dessem suporte para a mesma, a Apple e uma caso a parte, quer ser diferente, elitizada para faturar mais, basicamente falando. Mas a maior falha da Sun foi lancar o FX que deu um tiro no proprio pe, afinal colocou um produto muito similar ao ME com mais recursos visuais e todos que apostaram no ME se sentiram traidos com o FX pq se precisava de atualizacoes nas JVM para rodar o FX. Depois a Sun quiz colocar o FX como um concorrente do Flash e do Silverlight da MS que tambem nao enquadrou, a base ate hoje e minuscula de desenvolvedores e agora com a Oracle talvez nunca mais vai chegar la.
Java EE, aqui sim e o nicho do Java, e onde ele e forte e onde nas ultimas versoes teve as melhores melhorias, chamar atualmente o programador Java de futuro “COBOL guy” nao esta errado pois e o que ja esta acontecendo, vejo ainda muitos novos projetos sendo desenvolvidos em Java mas 95% deles para Web, e principalmente para Server side, ocupando o lugar de muitos sistemas que eram feitos em COBOL, muitas vezes. Sim nessa area nao se tem uma linguagem com tantos frameworks como Java. Struts e JSF 1.2 hoje sao os dominantes e deverao ficar por muito anos ainda, afinal empresas que gastam milhoes para criar um sistema nao vao trocar apos alguns anos somente pq um novo e melhor framework veio, eles sao vao trocar se trocar quando realmente nao tiver mais jeito, e ao meu ver eles estao certos, pois os sistemas adquiridos por elas sao mais uma engrenagem na maquina de fazer dinheiro.
Essa e a area em que o Java bate qualquer linguagem por uma larga margem, afinal e a unica lingugagem que e plataforma independente para servidores e possue muitos recursos mesmo para quem nao que mais usar EJB, existe muita coisa boa por ae, e por sinal muitas muito boas e de graca, sendo ao meu ver o Spring a melhor de todas e se voce tiver conhecimento suficiente de EJBs e Spring voce nao precisa de mais nada afinal os dois tem pontos muito fortes que podem ser aproveitados e bem. Em server side nada bate o java hoje e nao devera bater por muitos anos.
Agora no lado do cliente a coisa muda de figura, com as novas linguagens baseadas na JVM e mesmo Flash, Silverlight, PHP, ASP e outras muitas delas hoje tem muitos mais recursos para se desenvolver um Rich Client do que as tecnologias Java propriamente ditas, como JSF, Struts, Tapestry, JSP e por ai vai. Claro que se tivessemos IDEs com melhores suportes para a parte visual ajudaria em muito o desenvolvimento dessas, se voce acha que o Eclipse e NetBeans sao otimos, voce deveria dar uma olhada na IDE do .Net, que voce ira mudar radicalmente de ideia e bem rapido. Ja vi uns malucos fazendo sistemas para bancos em .Net para rodar me server side, e me garantiram que estava sendo uma tarefa herculea, devido a falta de recursos para o mesmo e muitos deles me falaram se fosse em Java estariam longe e com muito mais seguranca, o que acredito mesmo.
E ja vi muito tambem de programadores Java reclamando que para trabalhar com client side usando Java nao e tao facil qto usando algumas dessas linguagens que citei aqui em cima, principalemente se falando em manutencao, afinal 90% da vida de um sistema e manutencao e somente 10% e a concepcao do mesmo.
Agora a pergunta Java vai estar no meio de nos por muitos anos ainda ?
SIM definitivamente vai por muitos anos ainda, mas no seu nicho, nao consigo visualizar grandes projetos usando Java para o lado do cliente, tambem nao vi grandes melhorias no Java SE 7, e algumas boas no EE 6 (JSF 2.0 e EJB 3.1 sao as melhores). Tambem nao vejo muito mais o que “inventar” para colocar dentro do pacote, nao acredito tambem que a Oracle vai se empenhar tanto qto a Sun em prover um Java tao update e de graca, o que esta parecendo e que vai acontecer e uma ruptura e nao estar muito longe de acontecer, pois de um lado temos a Oracle que comprou a Sun recentemente e ainda ta pondo a casa no lugar, no outro temos a IBM que e a maior desenvolvedora de Java do mundo e ambas competem em muitas areas. E facil de ver que muitas das novas implementacoes do Java serao pagas e que a IBM nao vai deixar barato, se isso acontecer, e vai implementar suas necessidades na JVM logo em seguida. E com isso logo logo iremos ter duas JVMs, muito similares mas nao 100% compativeis.
Agora se voce quer um conselho em que linguagem comecar te dou tres escolhas e as tres sao OTIMAS, mas em primeiro lugar de todas para se aprender e a linguagem C, depois Java e .Net
E so ver que C roda em OS/390, Unix, Linux e Windows como Java, e .Net por causa do grande numero de plataformas Windows existente. Claro que ha as discrepancias, entre as plataformas, mas muito do codigo do C pode rodar em outras plataformas sendo somente recompilados na mesma.
O que esta faltau para o Java deslanchar nas outras areas que mencionei aqui, ao meu ver, foram uma JVM mais rapida e compacta, um JCP program mais eficaz e rapido ou quem sabe mesmo um gerador de codigo nativo, que vai contra a premissa da JVM mas que daria muito mais velocidade ao Java, ou mesmo um hardware da JVM que pudesse ter updates para ter as novas implementacoes ou mesmo algo hbrido, como algumas funcoes que nao se muda tanto da JVM em um processador, que pudesse ser setada na JVM ne, e outras ele usaria da JVM software. Acho que essa ansia por ter mais Java classes a cada versao nao foi e nao e saudavel para o Java em si, retrocompatibilidade e bom, mas ate um certo ponto, uma hora ira ter que haver uma ruptura para que se tenha algo com mais qualidade e melhor e que isso venha logo antes que seja tarde demais.
Hoje o Java ainda esta no embalo provido pela Sun no passado, mas logo logo isso vai passar se a Oracle nao se mobilizar e muito rapido. Se a Oracle realmente fazer a licao de casa e correr atras sim o Java podera se eternizar como linguagem, mas se nao, os programadores Java de hoje se tornacao os Coboleros de hoje no futuro.
Acho sim que Java e uma linguagem bem verbose, mas acho isso muito saudavel tb, afinal quem nunca teve problemas com aqueles milhares de processos invisiveis acontecendo por de tras dos bastidores sem que vc saiba, e que te tras um resultado que voce nao quer? E isso e um dos segredos do sucesso do Java sobre as outras linguagens, esse negocio de um comando ou classe fazer um mundo e utopico e ate a MS viu isso, por isso acho que isso e uma das forcas do Java tambem. Vale lembrar que o mercado de linguagens vale bilhoes hoje e que a MS NAO dorme no ponto.
Bom dei um cobrida bem superficial mesmo sobre o que se tem do Java e o que nao se tem uma olhada tb muito superficial nas especulacoes sobre o futuro do Java.
Por favor se voce tiver alguma duvida, nao gostar ou mesmo se falei alguma besteira aqui e so falar que posso corrigir, afinal como disse minha palavra nao e final. Mas por favor nao venha com grosserias ok.
Abs.
Tuesday 23 March 2010
Configurando o Tomcat 6 para rodar com o JBoss Seam
Ola pessoal apos um longo tempo sem postar, ME DESCULPEM, mas eu me mudei de pais e atualmente minha mulher esta com 6 meses do nosso primeiro filho, e ainda por cima estou envolvido em um projeto bem complicado com algumas tecnologias antigas.
Bom vamos la, para comecar se voce nao tiver algum desses, vai precisar fazer o download deles :
Java SE 5.0 - Nao adianta chorar, tem que ser o Java 5 mesmo isto ta no proprio site do Seam (http://www.seamframework.org/Download) bem como explicando as versao que servem para cada versao do JBoss AS. De uma olhada na.
A grosso modo o Seam 2.0 deve ser a versao que roda no Tomcat 6.
Apos voce instalar o Tomcat, e o JBoss Tools no Eclipse, resta fazer a configuracao (nao devo entrar nesses detalhes aqui, mas se for preciso, por favor me mandem um post e eu publico ok!)
Para o Tomcat voce comeca criando uma pasta dentro da pasta lib,
exemplo {Tomcat_home}/lib/seam
depois copie todos os Seam jars para dentro dela
Em {Tomcat_home}/conf/catalina.properties crie esta linha shared.loader=${catalina.home}/lib/seam/*.jar
embaixo desta : common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar
Se necessario faca a configuracao do vhost em {Tomcat_home}/conf/server.xml
Depois voce pode criar o data source no Tomcat, va em {Tomcat_home}/conf
No arquivo context.xml inclua algo similar, esse exemplo aqui e para o MySql
< Context crossContext="true" debug="5" docBase="seamweb" path="/seamweb" reloadable="true">
< Resource auth="Container" driverClassName="com.mysql.jdbc.Driver" maxActive="20" maxIdle="10" maxWait="-1" name="jdbc/seamweb" password="" type="javax.sql.DataSource" url="jdbc:mysql://localhost:3306/seamweb" username="edem"/>
< / Context>
Para mais informacoes a respeito de como configurar visite este link https://sec1.woopra.com/docs/jndi-datasource-examples-howto.html
Nele voce tera explicacoes para a maioria dos SGBDs existentes, esta em ingles mas e bem facil de entender.
Para configurar o Persistence.xml nao se esqueca de que o Tomcat nao tem um EJB container, entao tenha em mente que vc tera que deixar transaction-type como "RESOURCE_LOCAL"
e setar trocar a tag < jta> pela < non-jta-data-source> , setar tambem o database dialeto e o look default para o tomcat data source.
Neste link voce podera encontrar bons exemplos em como configurar o Tomcat com JPA, http://wiki.eclipse.org/EclipseLink/Examples/JPA/Tomcat_Web_Tutorial#JNDI_Datasource_Setup
Com isso voce com alguma nocao de JBoss Seam ja podera criar uma aplicacao usando o Tomcat. Nao se esqueca que para rodar aplicacoes no Tomcat elas precisam ser .WAR e nao .EAR ok. Se voce quizer usar recursos EJB eu repito novamente aqui, que voce use um AS que tenha EJB container, porem existe um workaround que e instalando o jboss-embedded . Porem ai sera necessario ler o tutorial do mesmo para ver como fazer a configuracao para rodar EJB dentro do Tomcat. Ao meu ver isso so e valido se voce ja possui aplicacoes rodando com o Tomcat e precisa incluir uma aplicacao que use EJB, caso contrario, repetindo, use um AS que tenha suporte para EJB.
Pessoal qualquer duvida mandem posts que vou responder.
Final de semana devo publicar o codigo de um micro projeto usando Seam e Tomcat.
Obrigado.
Bom vamos la, para comecar se voce nao tiver algum desses, vai precisar fazer o download deles :
Java SE 5.0 - Nao adianta chorar, tem que ser o Java 5 mesmo isto ta no proprio site do Seam (http://www.seamframework.org/Download) bem como explicando as versao que servem para cada versao do JBoss AS. De uma olhada na.
A grosso modo o Seam 2.0 deve ser a versao que roda no Tomcat 6.
Apos voce instalar o Tomcat, e o JBoss Tools no Eclipse, resta fazer a configuracao (nao devo entrar nesses detalhes aqui, mas se for preciso, por favor me mandem um post e eu publico ok!)
Para o Tomcat voce comeca criando uma pasta dentro da pasta lib,
exemplo {Tomcat_home}/lib/seam
depois copie todos os Seam jars para dentro dela
Em {Tomcat_home}/conf/catalina.properties crie esta linha shared.loader=${catalina.home}/lib/seam/*.jar
embaixo desta : common.loader=${catalina.home}/lib,${catalina.home}/lib/*.jar
Se necessario faca a configuracao do vhost em {Tomcat_home}/conf/server.xml
Depois voce pode criar o data source no Tomcat, va em {Tomcat_home}/conf
No arquivo context.xml inclua algo similar, esse exemplo aqui e para o MySql
< Context crossContext="true" debug="5" docBase="seamweb" path="/seamweb" reloadable="true">
< Resource auth="Container" driverClassName="com.mysql.jdbc.Driver" maxActive="20" maxIdle="10" maxWait="-1" name="jdbc/seamweb" password="" type="javax.sql.DataSource" url="jdbc:mysql://localhost:3306/seamweb" username="edem"/>
< / Context>
Para mais informacoes a respeito de como configurar visite este link https://sec1.woopra.com/docs/jndi-datasource-examples-howto.html
Nele voce tera explicacoes para a maioria dos SGBDs existentes, esta em ingles mas e bem facil de entender.
Para configurar o Persistence.xml nao se esqueca de que o Tomcat nao tem um EJB container, entao tenha em mente que vc tera que deixar transaction-type como "RESOURCE_LOCAL"
e setar trocar a tag < jta> pela < non-jta-data-source> , setar tambem o database dialeto e o look default para o tomcat data source.
Neste link voce podera encontrar bons exemplos em como configurar o Tomcat com JPA, http://wiki.eclipse.org/EclipseLink/Examples/JPA/Tomcat_Web_Tutorial#JNDI_Datasource_Setup
Com isso voce com alguma nocao de JBoss Seam ja podera criar uma aplicacao usando o Tomcat. Nao se esqueca que para rodar aplicacoes no Tomcat elas precisam ser .WAR e nao .EAR ok. Se voce quizer usar recursos EJB eu repito novamente aqui, que voce use um AS que tenha EJB container, porem existe um workaround que e instalando o jboss-embedded . Porem ai sera necessario ler o tutorial do mesmo para ver como fazer a configuracao para rodar EJB dentro do Tomcat. Ao meu ver isso so e valido se voce ja possui aplicacoes rodando com o Tomcat e precisa incluir uma aplicacao que use EJB, caso contrario, repetindo, use um AS que tenha suporte para EJB.
Pessoal qualquer duvida mandem posts que vou responder.
Final de semana devo publicar o codigo de um micro projeto usando Seam e Tomcat.
Obrigado.
Subscribe to:
Posts (Atom)
