Nível de conhecimento necessário para entender o artigo: você já entendeu mais ou menos o Java Core e gostaria de dar uma olhada nas tecnologias JavaEE e na programação web. Faz mais sentido se você estiver estudando atualmente a missão Java Collections, que cobre tópicos próximos ao artigo.
Atualmente estou usando o IntelliJ IDEA Enterprise Edition (esta é uma versão avançada paga do IDE, geralmente usada em desenvolvimento profissional -
nota do editor ). É muito mais fácil trabalhar com projetos web do que a Community Edition gratuita. Assim, na Enterprise Edition, literalmente com um clique do mouse, o projeto é montado, colocado em um contêiner de servlet, o servidor é iniciado e até uma página com o projeto em execução é aberta no navegador. Na versão gratuita da ideia, muito disso teria que ser feito de forma independente, por assim dizer, “manualmente”. Eu uso o Apache Maven para construir o projeto e gerenciar seu ciclo de vida. Nisso usei apenas uma pequena fração de seus recursos (gerenciamento de pacotes/dependências). Eu escolhi o Apache Tomcat versão 9.0.0.M4 como contêiner de servlet/servidor de aplicativos. Sei que já existem versões mais recentes, mas esta é a que instalei.
Vamos começar
Primeiro, vamos abrir o IntelliJ IDEA e criar um projeto Maven vazio.
Aqui à esquerda selecionamos Maven, verifique se o JDK do projeto está indicado no topo. Se não estiver lá, selecione o que você precisa na lista ou clique em Novo... e selecione diretamente no seu computador. No meio da janela tenho uma animação carregando a lista de arquétipos. Não precisamos deles, portanto, sem esperar o download, fique à vontade para clicar em Avançar na parte inferior da janela.
Nesta janela você precisa especificar
GroupId e ArtifactId . GroupId refere-se ao identificador exclusivo da empresa que produz o projeto. É prática comum utilizar o nome de domínio da empresa, mas na ordem inversa. Não no sentido de espelho, mas se, por exemplo, o nome de domínio de uma empresa
for maven.apache.org , então seu GroupId será
org.apache.maven . Ou seja, primeiro escrevemos o domínio de primeiro nível, separamos com um ponto, escrevemos o nome do domínio de segundo nível e assim por diante. Esta é a abordagem geralmente aceita. Caso você esteja “cortando” um projeto por conta própria, e não como parte de uma empresa, escreva aqui o seu nome de domínio pessoal (também na ordem inversa!). Se você tiver, claro :). Se não, não fique chateado. Na verdade, você pode escrever
qualquer coisa aqui .
Para uma empresa com o nome de domínio vasya.pupkin.org, o GroupId será org.pupkin.vasya. Essa abordagem de nomes é necessária para separar projetos com o mesmo nome, mas que foram lançados por empresas diferentes. |
Neste exemplo, usarei o nome de domínio fictício
fatfaggy.info.javarush.ru . Assim, insiro
ru.javarush.info.fatfaggy no campo GroupId .
ArtefactId é simplesmente o nome do nosso projeto. Você pode usar letras e alguns símbolos (hífens, por exemplo) para separar palavras. Nosso “artefato” será chamado exatamente como escrevemos aqui. Neste exemplo, escrevo
my-super-project . Não tocamos no campo de versão por enquanto, deixamos como está.
Bem, a janela IDEA padrão ao criar um novo projeto.
Vamos chamá-lo de meu superprojeto de acordo com a tradição .
O projeto foi criado!
O arquivo pom.xml abriu imediatamente na nossa frente. Este é um arquivo com configurações do Maven. Se quisermos “dizer” ao Maven o que e como fazer ou onde conseguir algo, descrevemos tudo isso neste mesmo arquivo pom.xml. Ele está localizado na raiz do projeto. |
Vemos que agora contém exatamente os dados que inserimos ao criar o projeto Maven:
groupId ,
artefatoId e
versão (não tocamos neste último).
Nossa estrutura de projeto
Este projeto Maven possui uma certa estrutura.
Como podemos ver, na raiz está:
- o diretório .idea , que contém as configurações da ideia para o projeto atual;
- o diretório src no qual criamos nossas fontes;
- arquivo my-super-project.iml , um arquivo de projeto criado por IDEA;
- arquivo pom.xml , o mesmo arquivo de projeto Maven de que falei acima, que agora abrimos. Se eu mencionar pom.xml ou “pom” em algum lugar, me referirei a este arquivo específico.
A pasta
src , por sua vez, contém duas subpastas:
- main - para nosso código;
- test - para testes do nosso código.
Tanto
main quanto
test possuem uma pasta
java . Considere que se trata da mesma pasta, apenas a principal
é para o código-fonte e a de
teste é para o código de teste, respectivamente. Não precisamos da pasta
de recursos por enquanto, não a usaremos. Mas deixe-o deitar.
Transformando-se em um projeto web
É hora de convertermos nosso projeto Maven em um projeto web. Para fazer isso, clique com o botão direito no nome do projeto nesta árvore e selecione
Adicionar suporte de estrutura...
Será aberta uma janela onde podemos adicionar suporte para todos os tipos de frameworks diferentes para o nosso projeto. Mas só precisamos de um:
Aplicativo Web . Nós o escolhemos.
Verificamos se há uma marca de seleção ao lado de
Web Application e na parte principal da janela observa-se que queremos que um arquivo
web.xml seja criado para nós imediatamente (recomendo marcar a caixa se não estiver lá). Depois disso, veremos que a estrutura do nosso projeto foi complementada com a pasta
web .
Esta é a raiz do nosso projeto web em
/ . Ou seja, se inserirmos o endereço localhost no navegador (ao iniciá-lo, é claro), ele será acessado exatamente aqui, na raiz do projeto web. Se inserirmos
localhost/addUser , a pasta
da web procurará um recurso chamado
addUser .
O principal é entender que a pasta web é a raiz do nosso projeto quando o carregamos no Tomcat. Agora temos uma certa estrutura de pastas, mas no projeto finalizado que iremos carregar, será um pouco diferente, e a pasta web será a raiz ali. |
Na
web existe uma pasta obrigatória chamada
WEB-INF , onde está localizado o arquivo
web.xml , que pedimos para criar na etapa anterior. Vamos abrir.
Como você pode ver, ainda não há nada de interessante nele, apenas o “chapéu”. Aliás, se não tivéssemos pedido para criá-lo, talvez tivéssemos que criá-lo manualmente, ou seja, digitar todo esse “cabeçalho” à mão, ou, em casos extremos, procurar uma versão pronta na Internet . Para que serve
o web.xml ? Para mapeamento. Aqui informaremos ao Tomcat quais solicitações de URL enviar para quais servlets. Mas isso é tudo mais tarde, por enquanto deixaremos em branco. Há também um arquivo chamado
index.jsp na pasta
web . Vamos abrir.
Este é o arquivo que será executado por padrão, por assim dizer. Ou seja, quando lançarmos o projeto, é exatamente isso que veremos. Em essência,
jsp é um arquivo html normal, com a diferença de que você pode executar código java nele.
Um pouco sobre conteúdo estático e dinâmico
Conteúdo estático é aquele que não muda com o tempo. Tudo o que escrevemos no arquivo html será exibido sem alterações. Se escrevemos olá mundo, então esta inscrição será exibida assim que abrirmos a página, e em 5 minutos, e amanhã, e em uma semana, e em um ano. Ela não vai mudar. Mas e se quisermos exibir a data atual na página? Se simplesmente escrevermos “27 de outubro de 2017”, amanhã veremos a mesma data, e em uma semana, e em um ano. Mas gostaria que esta data ainda fosse relevante. É aqui que a capacidade de executar algum código diretamente dentro da página vem em nosso auxílio. Podemos obter um objeto de data, convertê-lo no formato que precisamos e exibi-lo na página. Então todos os dias, sempre que abrirmos a página, a data será sempre relevante. Se precisarmos apenas de conteúdo estático, um servidor web normal e arquivos html serão suficientes para nós. Não precisamos de Java, Maven ou Tomcat. Mas se quisermos usar conteúdo dinâmico, é aqui que tudo isso será útil. Mas por enquanto vamos voltar ao nosso
index.jsp . Vamos indicar algo nosso em vez do cabeçalho padrão, por exemplo, “Meu super web-app!”, e no corpo escreveremos, por exemplo, “Estou vivo!” Estamos quase prontos para lançar nosso projeto! Mas, infelizmente, o habitual triângulo verde para o lançamento do programa não está ativo.
Vamos clicar no botão à esquerda dele (indicado na tela com uma seta vermelha) e selecionar
Editar configurações... Será aberta uma janela onde somos solicitados a clicar no sinal de mais verde para adicionar algum tipo de configuração. Clique nele, ele está localizado no canto superior esquerdo da janela.
Selecione o item
Servidor Tomcat e o
subitem Local. Uma janela será aberta com muitos parâmetros diferentes, mas estamos satisfeitos com quase tudo e com o padrão.
De alguma forma, podemos nomear bem nossa configuração em vez do padrão
Sem nome (no topo).
Também é necessário verificar se a ideia encontrou com sucesso o Tomcat em nosso sistema (você já baixou e instalou antes , certo?). Se você não conseguir encontrá-lo (o que é improvável), clique na seta para baixo e selecione onde o instalamos, ou outra versão, se você tiver vários deles. Eu tenho um e já está instalado, então está tudo como na imagem. E na parte inferior da janela vemos que há um aviso de que não há um único artefato destinado a implantação no servidor. E à direita desta inscrição existe um botão que oferece a correção deste defeito. Clicamos nele e vemos que a própria ideia encontrou tudo, criou tudo sozinha, o que faltava, e fez ela mesma todas as configurações.
Vemos que fomos transferidos da aba
Servidor para a aba Implantação , na seção
Implantar na inicialização do servidor já temos o artefato que precisa ser implantado, e abaixo está indicado que este artefato será construído antes da implantação.
Candidate-se, ok. E vemos que em primeiro lugar, na parte inferior da janela apareceu uma seção com nosso servidor Tomcat local, no qual nosso artefato será colocado. Você pode recolher esta seção clicando no botão correspondente no lado direito da janela.
Vemos também que o triângulo verde para lançamento já está ativo. Para quem quiser conferir tudo, pode clicar no botão com as configurações do projeto (à direita dos botões de lançamento, marcados com uma seta vermelha), ir até a seção
Artefatos e certificar-se de que o artefato foi realmente criado. Não estava lá até pressionarmos o botão
Fixar , mas agora está tudo bem. E esta configuração nos cai muito bem. Resumindo, a diferença entre
my-super-project:war e
my-super-project:war explodid é que
my-super-project:war criará apenas um arquivo
war (que é apenas um arquivo), e a opção com
explodiu é simplesmente
uma guerra “descompactada” . E esta opção é pessoalmente mais conveniente para mim, pois me permite implantar rapidamente pequenas alterações no servidor. Na verdade, o artefato é o nosso projeto, só que já compilado, e no qual a estrutura de pastas foi alterada para que possa ser carregado diretamente no Tomcat. Vai parecer algo assim:
Bom, agora está tudo pronto para lançar nosso projeto.
Pressionamos o cobiçado botão verde iniciar e aproveitamos o resultado! :)
GO TO FULL VERSION