Skip to content

4. Execução da aplicação

Pretendemos agora operar a aplicação fora dos controladores IDE e STS (para o servidor) e do Webstorm (para o cliente).

4.1. Implantação do serviço web num servidor Tomcat

Vimos no parágrafo 2.11.9 como criar um arquivo WAR para o Tomcat. Repetimos aqui o procedimento. Em primeiro lugar, para preservar o que já existe, duplicamos o projeto Eclipse [rdvmedecins-webapi-v3] para [rdvmedecins-webapi-v4].

  

O ficheiro [pom.xml] é alterado da seguinte forma:


    <modelVersion>4.0.0</modelVersion>
    <groupId>istia.st.spring4.mvc</groupId>
    <artifactId>rdvmedecins-webapi-v4</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>war</packaging>

    <name>rdvmedecins-webapi-v3</name>
    <description>Gestion de RV Médecins</description>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.0.0.RELEASE</version>
    </parent>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>istia.st.spring4.rdvmedecins</groupId>
            <artifactId>rdvmedecins-metier-dao-v2</artifactId>
            <version>0.0.1-SNAPSHOT</version>
        </dependency>
</dependencies>

As alterações devem ser feitas em dois locais:

  • linha 5: é necessário indicar que se vai gerar um arquivo WAR (Web ARchive);
  • linhas 23-27: é necessário adicionar uma dependência do artefacto [spring-boot-starter-tomcat]. Este artefacto inclui todas as classes do Tomcat nas dependências do projeto;
  • linha 26: este artefacto é o [provided], ou seja, os arquivos correspondentes não serão incluídos no WAR gerado. Com efeito, esses arquivos estarão disponíveis no servidor Tomcat onde a aplicação será executada;

Além disso, é necessário configurar a aplicação web. Na ausência do ficheiro [web.xml], isto é feito com uma classe que herda de [SpringBootServletInitializer]:

  

A classe [ApplicationInitializer] é a seguinte:


package rdvmedecins.web.config;

import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.context.web.SpringBootServletInitializer;

public class ApplicationInitializer extends SpringBootServletInitializer {
    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        return application.sources(AppConfig.class);
    }

}
  • linha 6: a classe [ApplicationInitializer] estende a classe [SpringBootServletInitializer];
  • linha 8: o método [configure] é redefinido (linha 7);
  • linha 9: é fornecida a classe [AppConfig], que configura o projeto;

Feito isto, poderá ser necessário atualizar o projeto Maven (eu tive de o fazer): [clic droit sur projet / Maven / Update project] ou [Alt-F5].

Para executar o projeto, pode-se proceder da seguinte forma:

  • no [1], executa-se o projeto num dos servidores registados no IDE Eclipse;
  • no [2], seleciona-se o [tc Server Developer], que está presente por predefinição. Trata-se de uma variante do Tomcat;

Obtém-se o seguinte resultado:

 

Isto é normal. Recorde-se que o serviço web não tem URL nem [/] nos seus métodos. Quando se tenta o URL e o [/getAllMedecins], obtém-se a seguinte resposta:

 

Isto é normal. O serviço web está protegido.

Agora, vamos iniciar o cliente [rdvmedecins-angular-v2] no WebStorm:

No [1], inserimos o URL do novo serviço web [http://localhost:8080/rdvmedecins-webapi-v4]. Obtemos o seguinte resultado:

Image

Para executar a aplicação fora do IDE STS, existem várias soluções. Aqui está uma delas.

Descarregue uma versão do Tomcat [http://tomcat.apache.org/download-80.cgi] (julho de 2014):

Selecione em [1] uma versão compactada e descompacte-a em [2]. Volte a STS:

  • no separador [Servers], clica-se com o botão direito do rato na aplicação [rdvmedecins-webapi-v4] e seleciona-se a opção [Browse Deployment Location];
  • em [4]: copie a pasta [rdvmedecins-webapi-v4];
  • no [5], cole a pasta [rdvmedecins-webapi-v4] na pasta [webapps] do Tomcat;
  • em [6], executa-se o ficheiro de comando [startup.bat] (o servidor Tomcat integrado em STS deve estar parado). Abre-se uma janela DOS para apresentar os registos do Tomcat. Estes devem indicar que a aplicação [rdvmedecins-webapi-v4] foi iniciada.

Para verificar isso, execute novamente o cliente Angular [rdvmedecins-angular-v2] no Webstorm:

No [1], insere-se o URL do novo serviço web [http://localhost:8080/rdvmedecins-webapi-v4]. Obtém-se o seguinte resultado:

Image

4.2. Implantação do cliente Angular no servidor Tomcat

Agora que o serviço web foi implementado no Tomcat, vamos implementar o cliente Angular num servidor também. Pode muito bem ser o servidor que já aloja o serviço web. Vamos seguir por este caminho.

Em primeiro lugar, duplicamos o cliente [rdvmedecins-angular-v2] para [rdvmedecins-angular-v3] e efetuamos as seguintes alterações:

  • em [1], tudo foi movido para uma pasta [app] ;
  • em [1], foi eliminada a pasta [bower-components], que continha as várias bibliotecas CSS e JS necessárias para o projeto. Todos estes elementos foram copiados para a pasta [lib] [2];
  • no [1], o ficheiro [app.html] foi renomeado para [index.html];

O ficheiro [index.html] foi alterado para ter em conta as alterações nos caminhos dos recursos utilizados:


<!DOCTYPE html>
<html ng-app="rdvmedecins">
<head>
  <title>RdvMedecins</title>
...
  <!-- o CSS -->
  ...
  <link href="lib/bootstrap-theme.min.css" rel="stylesheet"/>
  <link href="lib/bootstrap-select.min.css" rel="stylesheet"/>
</head>
<!-- controlador [appCtrl], modelo [app] -->
<body ng-controller="appCtrl">
<div class="container">
  ...
</div>
<!-- Núcleo do Bootstrap JavaScript ================================================== -->
<script type="text/javascript" src="lib/jquery.min.js"></script>
<script type="text/javascript" src="lib/bootstrap.min.js"></script>
<script type="text/javascript" src="lib/bootstrap-select.min.js"></script>
<script type="text/javascript" src="lib/footable.js"></script>
<!-- AngularJS -->
<script type="text/javascript" src="lib/angular.min.js"></script>
<script type="text/javascript" src="lib/ui-bootstrap-tpls.min.js"></script>
<script type="text/javascript" src="lib/angular-route.min.js"></script>
<script type="text/javascript" src="lib/angular-translate.min.js"></script>
<script type="text/javascript" src="lib/angular-base64.min.js"></script>
<!-- módulos -->
...
<!-- serviços -->
...
<!-- diretivas -->
...
<!-- controladores -->
....
</body>
</html>

Além disso, o controlador [loginCtrl] foi alterado para apontar para o servidor correto, de modo a evitar que o utilizador tenha de introduzir o seu URL:


// credenciais
app.serverUrl = "http://localhost:8080/rdvmedecins-webapi-v4";
app.username = "admin";
app.password = "admin";

Feito isto, vamos executar o ficheiro [index.html]:

Em seguida, liguemo-nos ao serviço web. Deve funcionar. Depois de verificado isto, desliguemos o servidor Tomcat. Vamos reutilizar o servidor integrado do STS.

No STS, vamos copiar todo o conteúdo da pasta [rdvmedecins-angular-v3/app] para a pasta [webapp] do projeto [rdvmedecins-webapi-v4] (separador Navigator) [1]:

Feito isto, inicie o [2], o servidor VMware do STS e, em seguida, solicite o URL [http://localhost:8080/rdvmedecins-webapi-v4/app/index.html]:

Temos um problema de direitos no [3]. Não é de admirar, uma vez que protegemos o serviço web. Temos de declarar que o acesso ao ficheiro [/app/index.html] é livre. Voltemos ao Eclipse:

  

Recordamos que os direitos de acesso foram definidos na classe [SecurityConfig]. Vamos alterá-la da seguinte forma:


    @Override
    protected void configure(HttpSecurity http) throws Exception {
        // CSRF
        http.csrf().disable();
        // a palavra-passe é transmitida através do cabeçalho Authorization: Basic xxxx
        http.httpBasic();
        // o método HTTP OPTIONS deve ser autorizado para todos
        http.authorizeRequests() //
                .antMatchers(HttpMethod.OPTIONS, "/", "/**").permitAll();
        // a pasta [app] está acessível a todos
        http.authorizeRequests() //
                .antMatchers(HttpMethod.GET, "/app", "/app/**").permitAll();
        // apenas a função ADMIN pode utilizar a aplicação
        http.authorizeRequests() //
                .antMatchers("/", "/**") // todos os URL
                .hasRole("ADMIN");
}
  • linhas 11-12: autorizamos todos a ler a pasta [app] e o seu conteúdo. Para o fazer, inspiramo-nos nas linhas anteriores.

Agora, reiniciemos o servidor Tomcat de STS e, em seguida, solicitemos novamente o URL [http://localhost:8080/rdvmedecins-webapi-v4/app/index.html]:

Image

Desta vez, está tudo bem.

4.3. Os cabeçalhos CORS

Talvez se lembrem que tivemos bastante dificuldade em lidar com os cabeçalhos CORS. No exemplo anterior:

  • o serviço web está em URL [http://localhost:8080/rdvmedecins-webapi-v4];
  • o cliente HTML está no URL [http://localhost:8080/rdvmedecins-webapi-v4/app];

O cliente HTML e o serviço web encontram-se, portanto, no mesmo servidor [http://localhost:8080]. Não há, portanto, conflitos CORS, uma vez que estes só ocorrem quando o cliente e o servidor não se encontram no mesmo domínio. Deveria ser possível verificar isso. Voltamos ao STS:

  

A geração ou não dos cabeçalhos CORS é controlada por um valor booleano definido na classe [ApplicationModel]:


    // dados de configuração
    private boolean CORSneeded = true;

Definimos o valor booleano acima para «false», reiniciamos o serviço web e voltamos a solicitar o URL [http://localhost:8080/rdvmedecins-webapi-v4/app/index.html]. Verificamos que a aplicação funciona.

4.4. Implementação do cliente Angular num tablet Android

A ferramenta [Phonegap] [http://phonegap.com/] permite gerar um executável para dispositivos móveis (Android, IoS, Windows 8, ...) a partir de uma aplicação HTML / JS / CSS. Existem várias formas de atingir este objetivo. Utilizamos a mais simples: uma ferramenta disponível online no site da Phonegap [http://build.phonegap.com/apps].

  • antes de [1], poderá ser necessário criar uma conta;
  • em [1], começamos;
  • em [2], escolhe-se um plano gratuito que permite apenas uma aplicação Phonegap;
  • em [3], descarregue a aplicação compactada [4] (a pasta [app] criada no parágrafo 4.2 está compactada);
  • em [5], atribua um nome à aplicação;
  • no [6], compila-se a aplicação. Esta operação pode demorar 1 minuto. Aguarde até que os ícones das diferentes plataformas móveis indiquem que a compilação está concluída;
  • apenas os binários para Android ([7]) e para Windows ([8]) foram gerados;
  • clique em [7] para descarregar o ficheiro binário do Android;
  • em [9], o ficheiro binário [apk] descarregado;

Inicie um emulador [GenyMotion] para um tablet Android (ver parágrafo 6.4):

 

Acima, iniciamos um emulador de tablet com o API 16 do Android. Assim que o emulador estiver a funcionar,

  • desbloqueie-o arrastando o fecho (se houver) para o lado e, em seguida, soltando-o;
  • com o rato, arraste o ficheiro [PGBuildApp-debug.apk] que descarregou e solte-o no emulador. Este será então instalado e executado;

É necessário alterar o URL para [1]. Para tal, numa janela de comando, digite o comando [ipconfig] (linha 1 abaixo), que irá apresentar os diferentes endereços IP do seu computador:


C:\Users\Serge Tahé>ipconfig

Configuration IP de Windows


Carte réseau sans fil Connexion au réseau local* 15 :

   Statut du média. . . . . . . . . . . . : Média déconnecté
   Suffixe DNS propre à la connexion. . . :

Carte Ethernet Connexion au réseau local :

   Suffixe DNS propre à la connexion. . . : ad.univ-angers.fr
   Adresse IPv6 de liaison locale. . . . .: fe80::698b:455a:925:6b13%4
   Adresse IPv4. . . . . . . . . . . . . .: 172.19.81.34
   Masque de sous-réseau. . . . . . . . . : 255.255.0.0
   Passerelle par défaut. . . . . . . . . : 172.19.0.254

Carte réseau sans fil Wi-Fi :

   Statut du média. . . . . . . . . . . . : Média déconnecté
   Suffixe DNS propre à la connexion. . . :

...

Anote quer o endereço Wi-Fi IP (linhas 6-9), quer o endereço na rede local IP (linhas 11-17). Em seguida, utilize este endereço IP no URL do servidor web:

 

Feito isto, ligue-se ao serviço web:

Teste a aplicação no emulador. Deve funcionar. Do lado do servidor, é possível autorizar ou não os cabeçalhos CORS na classe [ApplicationModel]: 


    // dados de configuração
    private boolean CORSneeded = false;

Isto não tem importância para a aplicação Android. Esta não é executada num navegador. Ora, a exigência dos cabeçalhos CORS provém do navegador e não do servidor.

4.5. Implantação do cliente Angular no emulador de um smartphone Android

Repetimos a operação anterior com um emulador de smartphone. Queremos verificar como o nosso cliente se comporta em ecrãs pequenos:

  • em [1], iniciamos um emulador de smartphone;
  • em [2] e [3], a barra de navegação foi recolhida num menu;
  • em [4], efetua-se o início de sessão;
  • em [5], a lista e o calendário estão um abaixo do outro, em vez de estarem lado a lado;
  • em [6], solicita-se a agenda;
  • em [7], como o ecrã é demasiado pequeno, parte dos horários fica oculta. Foi a biblioteca [footable] que realizou este trabalho;
  • em [8], a mesma vista que anteriormente, mas desta vez com um compromisso.

No final, a nossa aplicação adapta-se bastante bem ao smartphone. Certamente poderia ser melhor, mas continua a ser utilizável.

https://stahe.github.io
Este tutorial, escrito por Serge Tahé, é disponibilizado ao público sob os termos da Creative Commons Atribuição – Não comercial – Partilha igual 3.0 Unported.