quinta-feira, 26 de julho de 2007
terça-feira, 24 de julho de 2007
Configurando Virtual Host e Default Context no Tomcat
Bom, este post veio porque ontem ajudei um grande amigo meu com um probleminha neste aspecto. Queira aproveitar a oportunidade para deixar um grande abraço aqui pra ele, Daniel Kühl Lima, um dos únicos LPI3 do Brasil.
Normalmente quando você publica um servidor com um tomcat servindo uma aplicação, o que costuma-se fazer é simplesmente publicar a aplicação e passar a url para o usuário, por exemplo: www.meudominio.com.br:8080/aplicacao, e o usuário para acessar sua aplicação precisa digitar a url como consta ali, caso ele digita até o / ele irá cair naquela página default do tomcat, com links pra o Administrador e Manager.
Isso é beeem feio. Existe algumas maneiras de se fazer isso de uma forma mais "descente".
Primeiro, para melhorar, o usuário não precisa saber qual a porta para acessar a aplicação, então passar 8080 na url, é feio. Então o mais comum para arrumar isso é levantar o Tomcat com a porta 80. Para isso, é necessário alterar o arquivo [tomcatdir]/conf/server.xml trocando a porta na seguinte linha (normalmente está ~ pela linha 76):
< port="8080" maxhttpheadersize="8192">trocar a linha pela
< port="80" maxhttpheadersize="8192">Com isso resolvemos o problema de o usuário ter que digitar a porta 8080 na url. Porém, se o usuário digitar somente o seu domínio ele ainda acessará a página default do tomcat.
O que muita gente faz para corrigir isso, é instalar um Apache + Conector para Tomcat (para saber como configurar ver a documentação dos Connectors da Apache), e assim, ele configura para que o apache intermedie requisições para o tomcat, para que quando for acessado o raiz (www.meudominio.com.br) ele redirecione para a aplicação e pronto, o usuário não precisa mais saber qual o nome da aplicação.
Isso funciona. Mas para que ter que configurar mais uma coisa para acessar o tomcat, mais um possível ponto de erro!?
O que muita gente não sabe é que o próprio Tomcat tem suporte a Virtual Hosts.
Por default, o tomcat já vem com um Host configurado, que é justamente o raiz da aplicação, que é aquele host que está no arquivo server.xml.
< name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false">
< !-- UM MONTE DE COMENTÁRIO AQUI-- >
< /host >
Para configurar então o tomcat para que assim que o usuário digitar a url do seu domínio ela acesse diretamente sua aplicação, você pode apenas definir o Default Context.
< name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false">
< path="" docbase="aplicacao">
< /Host >
O path="" significa que será o context default, ou seja, assim que o usuário acessar o raiz de seu domínio, ele acessará a aplicação que você definiu no docBase.
Isto funciona para a maioria dos casos onde você tem apenas uma aplicação no servidor. Mas se você tiver um servidor que serve para vários domínios, você então precisará configurar Virtual Hosts, assim como era feito no Apache, quem administra servidores, sabe o que, e como fazer isso. Então, para fazer isso no Tomcat, basta você adicionar um novo Host, parecido com o do exemplo acima, porém, passando o domínio como name do host. Ex:
Agora, este novo host, você pode definir um context default ou não, isso depende da sua configuração. Caso você tenha multiplos domínios e apenas um servidor, basta ir adicionando eles a este arquivo. Lembre-se que todos os elementos Host ficam dentro do elemento Engine.
< name="www.meudominio2.com" appbase="/caminho/aplicacoes">
< path="" docbase="aplicacao2">
< /Host >
Nota importante:
Fiz alguns testes, e o tomcat se comportou de maneiras distintas em algumas versões diferentes. O que notei foi que o / tanto no appBase do Host, quanto no docBase do Context, faziam diferença. Então, caso não esteja conseguindo configurar, tente remover, ou inserir as barras tanto no início do caminho, quanto no final.
Bom, é isso, hoje não estou muito inspirado para escrever, então, eu sei que o post ficou com um português meio ruinzinho... Mas, sobretudo, espero ter ajudado alguém. Qualquer dúvida poste ai que eu tento responder.
[Update]
Para fazer isto no tomcat 6 mudou um pouquinho na parte de deixar o tomcat responder na porta 80 (primeira parte deste post). Mas não tem segredo, procure um "Connnector" no mesmo arquivo server.xml que contenha 8080, e altere para a porta 80 =) O resto continua a mesma coisa. Valeu.
quinta-feira, 19 de julho de 2007
JavaFX Script
Gostaria aqui de fazer um complemento sobre o meu post anterior sobre JavaFX onde falei basicamente sobre o JavaFX Mobile.
Estive no evento Falando em Java do pessoal da Caelum e teve uma excelente palestra sobre JavaFX com o Sérgio Lopes, onde ele demonstrou algumas coisas legais do JavaFX que na realidade eu não tinha visto no meu primeiro contato com ele, devido ao fato de eu estar mais focado na parte Mobile dele.
Vou relatar algumas aqui:
- Declarative Syntax
- Como era em Swing:
var win = new Frame();
win.title = "Hello World JavaFX";
win.width = 200;
var label = new Label();
label.text = "Hello World";
win.content = label;
win.visible = true;
Como é em JavaFX:
import javafx.ui.*;
Frame {
title: "Hello World JavaFX"
width: 200
height: 50
content: Label {
text: "Hello World"
}
visible: true
}- Data Binding
- Você passa um objeto.atributo como valor de um campo e ele automáticamente atualiza este atributo de tal objeto.
- Facilidade de Leitura
- Facilidade de visualizar a estrutura da tela já no Código, por que fica algo bem "hierárquico" em código, e não aquela coisa bagunçada do Swing
Segundo o Sérgio, o JavaFX ainda está em uma versão "super-early-alpha", e NÃO DEVE ser usada em produção ainda. Mas pelo jeito haverá muito investimento nela neste e no próximo ano.
Tutorial sobre JavaFX Script
-----
Estava com este post enroscado por mais de uma semana esperando que o pessoal la da Caelum postasse sobre esta palestra =)
Postado por
Unknown
às
10:44
0
comentários
quarta-feira, 18 de julho de 2007
Eclipse 3.3
Como todos sabem o eclipse 3.3 (aka Europa) lançou a algumas semanas atrás (eu sempre atrasado) e está bem legalzinho. Com algumas firulinhas a mais e com uma carinha mais "clean" eu achei =)
Bom algumas features me chamaram a atenção:
- Começando pela página de download! (que maravilha aquilo né!?)
- Não precisa mais baixar todos os milhares de plugins básicos
- Integração nativa com o Mylyn (Antigo Mylar) Task-Focused Development
- Copy Qualified Name (ao menos eu acho, ou veio junto com meu workspace antigo)
- Melhoras no Refactoring e Quick-Fix
- Suporte nativo a JPA, WebService...
- Suporte para Annotation (com auto-complete =] )
Ahhh, gostei desta dica do Rafael Carneiro.
Postado por
Unknown
às
11:01
0
comentários
Problema ao gerar Jar com suas dependencias
Bah... eu não sou nem um pouco bom para fazer esses títulos ;)
Mas é o seguinte, esses dias estava em um projeto com um colega de trabalho, e estava desenvolvendo uma aplicaçãozinha que iria ficar rodando num servidor verificando alguns erros, e interagindo com uma outra aplicação. Fizemos a app e pusemos ela rodar no servidor, maravilha!
Rodamos ela fez o que tinha que fazer e beleza. Depois fomos testar ela novamente e misteriosamente não rodava mais! Nem a que estava na minha máquina de desenvolvimento resolvou não rodar mais. Dava um monte de erro de NoClassDefFoundError e NullPointerException.
Depois de algum tempo verificamos que tinha um monte de dependencias faltando, os xalan-xerxes da vida e todas aquelas dependências. Maravilha colocamos a app rodar e foi =) Problemas resolvidos, correto?!
Errado! Começou a gerar outros erros de .properties faltando! Fui procurar no build.xml e na hora que ele fazia o unjar dos .jar de dependencias do projeto, para depois jogar tudo dentro de um jar só no final, ele tinha uma propriedade que só pegava os .class dos jars e excluia tudo o resto. Ok, retirei a linha de restrição, e tudo passou a funcionar normalmente.
Pergunta: Porque funcionou da primeira vez?!
Agora uma outra historinha. Sabe o projeto de onde copiei o build? Então, este projeto está em produção a mais de 1 ano! Exatamente (pasme). Ele foi uma das heranças dadas a mim assim que entrei na empresa.
Coincidentemente uma semana após eu ter arrumado este erro no primeiro projeto, aquele que já estava em produção pipocou! Não rodou mais, começou a dar falhas, e não fazia mais o que tinha que fazer, foi um desesperto geral ontem aqui, pq era um problema seríssimo. Fui então correr atrás da causa, e me lembrei do ocorrido na semana passada, verifiquei que alguns erros que geravam era por causa de .properties que estavam faltando no .jar do projeto que roda la no servidor.
Guardamos arquivos de logs diários, dos ultimos 3 meses, e fui verificar os logs, este erro era recorrente. Sempre aconteceu, mas resolveu que de uma hora pra outra resolveu parar. O mais estranho, é que dei um kill no processo la no servidor, e então levantei o processo novamente, e tudo voltou a funcionar normalmente.
Pergunta: "Como pode uma porra dessa bátima?!"
Alguém já passou por isso? Alguém já viu algo parecido? Eu achei estranhíssimo! Por que o negócio sempre rodou, já faz mais de 1 ano, e agora resolveu pipocar de uma hora pra outra. E era uma coisa que estava faltando que deveria afetar sempre!
Por favor, alguém tem uma explicação racional para isso?! Agradeço se puder postar aqui.
-------------
ps: vou fazer um post sobre como gerar um build.xml descompactando os .jars e colocando tudo em um .jar só. Mas eu ainda acho mais correto exportar o Classpath colocando tudo em um diretório .lib as dependências. Muito mais "seguro" =)
Postado por
Unknown
às
10:00
0
comentários
Marcadores: dependencias, jar, noclassdeffounderror, nullpointerexception, problema, properties
