Deployando sua aplicação com o Spring Boot

Já escrevi aqui no blog, duas vezes, o quanto o Spring Boot pode nos ajudar no desenvolvimento das aplicações. Levou ao extremo o termo convenção sobre configuração e realmente deixou tudo muito mais simples. Um ponto que eu ainda não comentei foi sobre o processo de deploy, se você tiver escolhido o JSP como tecnologia de view. Caso tenha escolhido outras, como o ascendente Thymeleaf, o processo de deploy é o mais simples possível, já que é só gerar o jar e rodar. Em outro post eu comento porque eu escolhi não trocar de tecnologia de view.

O processo até é bem documentado no site, mas acho que alguns pontos merecem um reforço. O primeiro é justamente o fato de termos escolhido JSP como view. O Spring Boot configura o Tomcat para sempre procurar as páginas a partir do caminho src/main/webapp, relativo ao ponto de execução do seu jar. Só que esses arquivos não são copiados quando você executa um mvn clean install, ou seja, você precisa colocar no seu script de deploy um passo para copiar a estrutura e jogar no mesmo local do seu jar executável. Caso você seja curioso, dê uma olhada nesse commit e veja os valores fixos na classe.  A própria documentação sugere que você não deve usar o jar executável quando estiver com jsps.

Para contornar esse problema e deixar, pelo menos para mim, tudo um pouco mais simples, podemos recorrer a um outro plugin do maven que também roda um tomcat embedded, só que referenciando um war.  O webapp-runner gera para você um jar que sobe o tomcat e permite que você passe como argumento o caminho para um arquivo war.

java -jar dependency/webapp-runner.jar tudosobreesporte-1.0.0-SNAPSHOT.war

Para usá-lo, basta que você adicione a seguinte entrada no seu pom.xml. 

	<plugin>
		<groupId>org.apache.maven.plugins</groupId>
		<artifactId>maven-dependency-plugin</artifactId>
		<executions>
			<execution>
				<phase>package</phase>
				<goals>
					<goal>copy</goal>
				</goals>
				<configuration>
					<artifactItems>
						<artifactItem>
							<groupId>com.github.jsimone</groupId>
							<artifactId>webapp-runner</artifactId>
							<version>7.0.57.2</version>
							<destFileName>webapp-   runner.jar</destFileName>
						</artifactItem>
					</artifactItems>
				</configuration>
			</execution>
		</executions>
	</plugin>

Além disso você precisa fazer só mais algumas alterações no seu pom.xml. Quando o SetupMyProject gera o seu projeto para o Spring Boot, o tipo de projeto é jar, justamente porque é o que precisa para você subir uma aplicação com o Spring Boot em dev. Você precisa trocar o tipo para war.

  <packaging>war</packaging>

Outro detalhe importante é que precisamos apagar o plugin do Spring Boot que gera um fat jar quando executamos um mvn install. 

        <!-- apague esse trecho -->
	<plugin>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-maven-plugin</artifactId>
	</plugin>

Só que agora surgiu um possível problema. Quando gerávamos o jar com tudo dentro, era também incorporado uma classe específica do Spring Boot que usava a classe do nosso projeto que possuía o método main, geralmente aquela que chamamos de Boot,  para conseguir dar o start no nosso projeto. Isso é tão verdade que se você tiver mais de uma classe no projeto com o método main, dá erro de execução quando vamos rodar o mvn install com o plugin do boot. Agora que temos um war, que vai ser carregado normalmente pelo Servlet Container, precisamos voltar a estratégia padrão do Spring MVC, ou seja, é necessário ter uma classe que implemente a interface WebApplicationInitializer. 

Para a nossa sorte o Spring Boot já possui uma implementação dessa interface justamente pensando nesse estilo de deploy :). Basta que a sua classe que tem o main e que, geralmente, também tem a annotation SpringBootApplication, herde de SpringBootServletInitializer.  Não teria problema alguma se você optasse por criar uma classe separada e herdasse também, fiz direto na classe Boot apenas pela facilidade.

  public class Boot extends SpringBootServletInitializer {
    ...
  }

Para fechar, precisamos indicar para a classe SpringBootServletInitializer quais as nossas classes responsáveis pela configuração do nosso projeto.

	@Override
	protected SpringApplicationBuilder configure(
			SpringApplicationBuilder application) {
		return application.sources(Boot.class);
	}

Repare que eu passei como argumento a própria classe anotada com SpringBootApplication, já que essa annotation já define que todas as classes, a partir do pacote onde ela está declarada, devem ser scaneadas.

Agora que já ajustamos o código precisamos só prestar atenção em último detalhe. O tempo inteiro numa aplicação com o Spring Boot usamos o arquivo application.properties. Só que quando vamos para produção, em geral vamos ter outras configurações. Alguns exemplos:

1. Nome e dados de acesso do banco de dados
2. Caminhos para escrita de arquivos

Essa ideia de environment já é bem suportada pelo Spring e o Spring Boot tira apenas proveito. Na hora que você passe o argumento -Dspring.profiles.active atribuindo o valor de ambiente que você quer.

  java -Dspring.profiles.active=production -jar webapp-runner.jar tudosobreesporte-1.0.0-SNAPSHOT.war& 

No exemplo acima você está ensinando ao Spring Boot a procurar por um arquivo chamado application-production.properties :).

É importante ressaltar que você pode continuar, em dev, executando a classe Boot. A única diferença é que em ambiente de produção você agora roda um war convencional.

O post de hoje teve mais o objetivo de centralizar algumas informações importantes sobre deploy de uma aplicação usando o Spring Boot. Como já comentei, o mundo do Spring é gigante e, se tiver algum assunto que você esteja mais interessado, não deixe de comentar ;).