Vai ser um post longo, pois a ideia \u00e9 que sirva de refer\u00eancia no futuro. :)<\/p>\n\n\n\n
Conceitos essenciais<\/h1>\n\n\n\n![\"The](\"https:\/\/mymodernmet.com\/wp\/wp-content\/uploads\/2018\/08\/school-of-athens-raphael-2.jpg\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Sabe aonde mora a maior parte das d\u00favidas relativas a este tema? Aus\u00eancia de conhecimento conceitual. Vamos dar nomes \u00e0s coisas aqui pra tornar nossa vida mais f\u00e1cil. Iremos percorrer tr\u00eas andares deste edif\u00edcio conceitual para que voc\u00ea possa ver desde os pontos mais elementares at\u00e9 os mais abstratos.<\/p>\n\n\n\n
Primeiro andar: Java<\/h2>\n\n\n\n![\"Java\"](\"https:\/\/devkico.itexto.com.br\/wp-content\/uploads\/2009\/10\/java_logo_2.png\")
<\/figure><\/div>\n\n\n\nEm Java voc\u00ea tem diversas fontes para suas configura\u00e7\u00f5es: arquivos de prorpriedades (properties), vari\u00e1veis de ambiente, vari\u00e1veis de sistema… Responda rapidamente, olhando o Javadoc da classe java.lang.System, voc\u00ea consegue explicar de forma imediata a diferen\u00e7a entre os m\u00e9todos getenv() e getProperty()?<\/p>\n\n\n\n![\"javadoc](\"https:\/\/devkico.itexto.com.br\/wp-content\/uploads\/2020\/11\/image.png\")
<\/figure>\n\n\n\nO nome dos m\u00e9todos j\u00e1 inicia uma pequena confus\u00e3o: por que “getenv” e n\u00e3o “getEnv”? O primeiro conceito ent\u00e3o a tratar ser\u00e1 a diferen\u00e7a entre “environment variable” (vari\u00e1vel de ambiente) e “system property” (propriedade do sistema). <\/p>\n\n\n\n
Vari\u00e1veis de ambiente<\/h3>\n\n\n\n
Vari\u00e1vel de ambiente \u00e9 aquela que voc\u00ea define no sistema operacional em que seu c\u00f3digo \u00e9 executado. No caso do Linux (e macOS) o fazemos com os comandos set e export<\/a>. J\u00e1 no caso do Windows \u00e9 com o comando set (mais comum) ou a partir do utilit\u00e1rio de configura\u00e7\u00e3o gr\u00e1fica de ambiente, tal como na imagem abaixo:<\/p>\n\n\n\n![\"Vari\u00e1veis](\"https:\/\/www.computerhope.com\/issues\/pictures\/win10-envirvariables.jpg\")
<\/figure><\/div>\n\n\n\nVamos ent\u00e3o a um exemplo bem simples: imagine que estou no Linux e usando o comando export eu defina a vari\u00e1vel de ambiente nome<\/em> com o valor Kico<\/em>, tal como no script a seguir:<\/p>\n\n\n\nexport nome=Kico<\/pre>\n\n\n\nE na sequ\u00eancia eu tenha o seguinte c\u00f3digo Java:<\/p>\n\n\n\n
System.out.println(System.getenv(\"nome\");<\/pre>\n\n\n\nA sa\u00edda ser\u00e1…<\/p>\n\n\n\n
Kico<\/pre>\n\n\n\nResumindo: temos aqui vari\u00e1veis do sistema operacional que s\u00e3o completamente externas ao nosso c\u00f3digo.<\/em><\/strong> Quer ser aprofundar no tema envolvendo Java? Este \u00e9 o link<\/a>.<\/p>\n\n\n\nPropriedades do sistema<\/h3>\n\n\n\n
Aqui mora a confus\u00e3o. Propriedades do sistema (System Properties) s\u00e3o configura\u00e7\u00f5es que toda aplica\u00e7\u00e3o Java mant\u00e9m em mem\u00f3ria que dizem respeito ao seu ambiente de execu\u00e7\u00e3o. Algumas destas propriedades s\u00e3o padr\u00e3o como, por exemplo, “user.home”, que diz qual o diret\u00f3rio home do usu\u00e1rio, “os.name”, que diz qual o sistema operacional no qual a aplica\u00e7\u00e3o est\u00e1 sendo executada, etc.<\/p>\n\n\n\n
Estas propriedades s\u00e3o portanto impl\u00edcitas (como as que mencionei acima) ou expl\u00edcitas. As expl\u00edcitas s\u00e3o aquelas que passamos para o comando java usando argumentos que come\u00e7am com “-D”. Imagine que eu tenha um programa Java tal como o apresentado a seguir:<\/p>\n\n\n\n
public class Programa {\n public static void main(String args[]) {\n System.out.println(System.getProperty(\"nome\"));\n }\n}<\/code><\/pre>\n\n\n\nCompilado meu programa, e executando-o com o comando abaixo, a sa\u00edda ser\u00e1 “Kico”<\/p>\n\n\n\n
java -Dnome=Kico<\/strong> Programa<\/pre>\n\n\n\nEnt\u00e3o, simplificando, as propriedades do sistema s\u00e3o as impl\u00edcitas da plataforma de execu\u00e7\u00e3o e aquelas que passamos por linha de comando ao nosso programa Java<\/strong>. Quer se aprofundar no assunto e conhecer as propriedades padr\u00e3o? Este \u00e9 o link<\/a>.<\/p>\n\n\n\nSegundo andar: Spring<\/h2>\n\n\n\n![\"Spring\"](\"https:\/\/devkico.itexto.com.br\/wp-content\/uploads\/2010\/11\/spring_logo.gif\")
<\/figure><\/div>\n\n\n\nPropriedades (Properties)<\/h3>\n\n\n\n
Do ponto de vista de quem usa o Spring n\u00e3o h\u00e1 vari\u00e1veis de ambiente ou propriedades do sistema, h\u00e1 apenas propriedades (Properties)<\/strong>. Uma propriedade \u00e9 uma informa\u00e7\u00e3o de configura\u00e7\u00e3o no formato chave\/valor. Toda propriedade portanto \u00e9 identificada por uma chave e possui um valor associado a esta.<\/p>\n\n\n\nPense no conceito de property (usarei o termo em ingl\u00eas daqui pra frente pois \u00e9 o que voc\u00ea encontrar\u00e1 na esmagadora maioria das documenta\u00e7\u00f5es e literatura relacionada) como a unidade mais fundamental de configura\u00e7\u00e3o no Spring. O objetivo das abstra\u00e7\u00f5es sobre as quais falarei a respeito agora tem como objetivo obter estas informa\u00e7\u00f5es e organiz\u00e1-las para voc\u00ea.<\/p>\n\n\n\n
Environment (Ambiente)<\/h3>\n\n\n\n
Esta abstra\u00e7\u00e3o consiste em uma interface<\/a> do container Spring que ser\u00e1 usada para modelar outro aspecto fundamental do framework: os perfis (profiles). Antes de falarmos sobre esta outra abstra\u00e7\u00e3o \u00e9 importante refletir um pouco sobre o que v\u00eam a ser um Environment.<\/p>\n\n\n\nO Environment representa na pr\u00e1tica o ambiente de execu\u00e7\u00e3o da sua aplica\u00e7\u00e3o. \u00c9 ele que diz quais vari\u00e1veis de ambiente estamos usando, quais beans dever\u00e3o ser instanciados e tamb\u00e9m quais os perfis que est\u00e3o ativos ou que ser\u00e3o ativados pela nossa aplica\u00e7\u00e3o. Antes de falar sobre os perfis \u00e9 importante mencionar um elemento bastante usado por este componente: a property source<\/em>.<\/p>\n\n\n\nProperty Source<\/h3>\n\n\n\n
Sua fun\u00e7\u00e3o consiste em representar uma fonte de dados da qual iremos obter nossas listas de propriedades. Esta fonte de dados pode ser literalmente qualquer coisa: arquivos, web services, bancos de dados, sistemas gestores de configura\u00e7\u00e3o como o Spring Cloud Config Server<\/a>, etc.<\/p>\n\n\n\nEm aplica\u00e7\u00f5es Spring Boot quando desejamos externalizar o acesso aos arquivos de configura\u00e7\u00e3o usamos a anota\u00e7\u00e3o @PropertySource<\/a> tal como no exemplo a seguir:<\/p>\n\n\n\n@PropertySource(\"file:\/\/\/home\/kicolobo\/configsfelizes.properties\")<\/strong>\npublic class AplicacaoSpringBoot {\n ...\n}<\/pre>\n\n\n\nE, claro, caso nenhuma das op\u00e7\u00f5es providas pelo framework n\u00e3o lhe atendam, basta que voc\u00ea implemente o seu pr\u00f3prio Property Source e registrando-o no Spring, o que foge do assunto deste post.<\/p>\n\n\n\n
Profiles (Perfis) – muita aten\u00e7\u00e3o aqui!<\/strong><\/h3>\n\n\n\n![\"Foto](\"https:\/\/images.pexels.com\/photos\/1093087\/pexels-photo-1093087.jpeg?auto=compress&cs=tinysrgb&h=750&w=1260\")
<\/figure><\/div>\n\n\n\nUma aplica\u00e7\u00e3o Spring Boot ao ser executada pode ter n perfis, mas o que \u00e9 um perfil? O profile identifica um conjunto de configura\u00e7\u00f5es que definem como a sua aplica\u00e7\u00e3o deve se portar em um dado ambiente de execu\u00e7\u00e3o. \u00c9 muito importante aqui saber a diferen\u00e7a entre profiles e ambientes de execu\u00e7\u00e3o, pois muitas vezes estes s\u00e3o usados de modo intercambi\u00e1vel:<\/p>\n\n\n\n
- Ambiente de execu\u00e7\u00e3o<\/strong> – onde sua aplica\u00e7\u00e3o est\u00e1 sendo executada. Exemplo: ambiente de desenvolvimento, execu\u00e7\u00e3o de testes, produ\u00e7\u00e3o, homologa\u00e7\u00e3o, etc.<\/li>
- Profile (Perfil)<\/strong> – um conjunto l\u00f3gico de configura\u00e7\u00f5es que define como sua aplica\u00e7\u00e3o ir\u00e1 ser executada.<\/strong><\/li><\/ul>\n\n\n\n
Ent\u00e3o voc\u00ea pode, por exemplo, ter perfis que identifiquem o tipo de persist\u00eancia que seu projeto est\u00e1 usando. Exemplo<\/strong>: um perfil chamado Relacional<\/em> que indica que estamos usando datasources contra uma base de dados relacional e outro chamado NoSQL<\/em> que indica que estamos usando bases de dados n\u00e3o relacionais.<\/p>\n\n\n\nE voc\u00ea pode ter este mesmo perfil aplicado a diferentes ambientes de execu\u00e7\u00e3o: imagine o perfil NoSQL<\/em> aplicado aos ambientes de Produ\u00e7\u00e3o e Desenvolvimento, enquanto o perfil Relacional<\/em> apenas no ambiente de homologa\u00e7\u00e3o.<\/p>\n\n\n\nVoltando ao exemplo dos profiles NoSQL<\/em> e Relacional<\/em>, \u00e9 fundamental saber<\/strong> que o Profile n\u00e3o indica apenas o conjunto de propriedades (properties<\/em>) que ir\u00e3o ser carregadas, mas tamb\u00e9m quais beans<\/em> ser\u00e3o instanciados<\/strong>. Voltando ao exemplo, podemos ter configura\u00e7\u00f5es de DAO implementadas tal como no exemplo a seguir:<\/p>\n\n\n\n@Configuration<\/strong>\npublic class ConfiguracaoDAO {\n @Bean @Profile(\"Relacional\")<\/strong>\n public DAOUsuario getDAORelacional() {\n return new DAOUsuarioMySQL();\n }\n\n @Bean @Profile(\"NoSQL\")<\/strong>\n public DAOUsuario getDAONaoRelacional() {\n return new DAOUsuarioMongoDB()\n }\n}<\/pre>\n\n\n\nProgramando contra interfaces a classe cliente nem sonha que DAOUsuario<\/em> \u00e9 usado contra o MongoDB ou MySQL, mantemos assim a boa pr\u00e1tica de programar contra interfaces e n\u00e3o implementa\u00e7\u00f5es.<\/p>\n\n\n\nMas a\u00ed voc\u00ea me pergunta: como eu defino o profile adotado?<\/p>\n\n\n\n
Selecionando os profiles<\/h4>\n\n\n\nPor system property<\/h5>\n\n\n\n
\u00c9 f\u00e1cil, e aqui entra aqueles pontos que voc\u00ea deve decorar<\/strong>. Primeiro a forma mais simples, que \u00e9 a partir da linha de comando: voc\u00ea usa a system property<\/strong> spring.profiles.active<\/em>. Vamos a um exemplo:<\/p>\n\n\n\njava -Dspring.profiles.active=prod AplicacaoLinda.jar<\/pre>\n\n\n\nDefinimos que nossa aplica\u00e7\u00e3o ir\u00e1 executar usando o profile prod<\/em>. E se eu quiser usar mais de um profile ao mesmo tempo? E se eu quiser usar os profiles prod e relacional? Separe com v\u00edrgulas:<\/p>\n\n\n\njava -Dspring.profiles.active=prod,relacional AplicacaoSuperPoderosa.jar<\/pre>\n\n\n\nMas h\u00e1 outras maneiras: voc\u00ea pode definir o profile por arquivos de configura\u00e7\u00e3o, Maven, em tempo de execu\u00e7\u00e3o e outros. Este link aqui<\/a> pode te ensinar estas outras maneiras.<\/p>\n\n\n\n![\"Aten\u00e7\u00e3o\"](\"https:\/\/images.pexels.com\/photos\/2743739\/pexels-photo-2743739.jpeg?auto=compress&cs=tinysrgb&h=750&w=1260\")
<\/figure><\/div>\n\n\n\nSe eu n\u00e3o selecionar um profile, que profile \u00e9 carregado?<\/strong> <\/strong>O profile default<\/strong>. Importante que voc\u00ea tenha esta informa\u00e7\u00e3o em mente. No Spring Boot n\u00e3o existem profiles como dev, prod, test<\/em> por padr\u00e3o, mas como vemos em diversos posts, acabamos por achar que eles existem no framework.<\/p>\n\n\n\n<\/p>\n\n\n\n
Programaticamente <\/h5>\n\n\n\n
Antes da aplica\u00e7\u00e3o ser iniciada, no m\u00e9todo main, voc\u00ea pode usar o m\u00e9todo setAdditionalProfiles<\/em> da classe SpringApplication<\/em>. Importante voc\u00ea saber que ap\u00f3s a aplica\u00e7\u00e3o ter sido iniciada n\u00e3o \u00e9 mais poss\u00edvel trocar o perfil (at\u00e9 onde sei). Mais detalhes sobre os perfis do Spring Boot neste link<\/a>.<\/p>\n\n\n\nTerceiro andar: Spring Boot e suas auto configura\u00e7\u00f5es<\/h2>\n\n\n\n![\"Spring](\"https:\/\/pbs.twimg.com\/profile_images\/1235868806079057921\/fTL08u_H_400x400.png\")
<\/figure><\/div>\n\n\n\nCalma, \u00e9 o \u00faltimo andar MESMO agora (por enquanto, pois n\u00e3o vou falar aqui do Spring Cloud). O Spring Boot adiciona mais uma abstra\u00e7\u00e3o importante referente a configura\u00e7\u00f5es: as auto configura\u00e7\u00f5es.<\/strong><\/p>\n\n\n\nMuita gente ignora este aspecto do “Boot”: o framework \u00e9 composto por diversos m\u00f3dulos que voc\u00ea pode adicionar ao seu projeto, identificados no Maven\/Gradle com o nome “spring-boot-starter-*”, e cada um destes m\u00f3dulos cont\u00e9m, al\u00e9m das suas pr\u00f3prias funcionalidades, suas pr\u00f3prias configura\u00e7\u00f5es (auto configura\u00e7\u00f5es), ativadas no momento em que a aplica\u00e7\u00e3o \u00e9 iniciada.<\/p>\n\n\n\n
\u00c9 fundamental que voc\u00ea saiba disto<\/strong> por que temos aqui aplicado o conceito de conven\u00e7\u00f5es sobre configura\u00e7\u00e3o. O autor do m\u00f3dulo define qual ser\u00e1 o seu comportamento padr\u00e3o e cabe a voc\u00ea customizar o que \u00e9 necess\u00e1rio para o seu projeto.<\/strong> Mas a\u00ed entra a seguinte quest\u00e3o: como saber quais s\u00e3o estas configura\u00e7\u00f5es? Simples: voc\u00ea executa sua aplica\u00e7\u00e3o com o par\u00e2metro –debug e todas ser\u00e3o impressas no console. Exemplo:<\/p>\n\n\n\njava --debug -jar AplicacaoLinda.jar<\/pre>\n\n\n\nE se eu estiver usando Maven ou Gradle no meu ambiente de desenvolvimento? D\u00e1 pra passar o par\u00e2metro tamb\u00e9m.<\/p>\n\n\n\n
Sendo assim se voc\u00ea usa, por exemplo, o m\u00f3dulo JPA do Spring Boot: spring-boot-starter-jpa<\/em>, automaticamente \u00e9 configurado um datasource para voc\u00ea. E estas configura\u00e7\u00f5es variam de m\u00f3dulo para m\u00f3dulo, mas n\u00e3o fique triste. Mas como estas configura\u00e7\u00f5es s\u00e3o carregadas e onde est\u00e3o?<\/p>\n\n\n\nNo momento em que a aplica\u00e7\u00e3o \u00e9 iniciada o Spring varre todos os arquivos JAR presentes no seu classpath que perten\u00e7am a estes m\u00f3dulos. E em cada um destes busca por um arquivo chamado spring.factories<\/em>, presente no diret\u00f3rio META-INF<\/em> do JAR. Neste arquivo est\u00e3o listadas as classes de configura\u00e7\u00e3o (@Configuration) que s\u00e3o as respons\u00e1veis por configurar aquele m\u00f3dulo.<\/p>\n\n\n\nDica<\/strong>: leia este t\u00f3pico<\/a> da documenta\u00e7\u00e3o oficial do Spring Boot para entender como estes m\u00f3dulos s\u00e3o escritos.<\/p>\n\n\n\nCarregando configura\u00e7\u00f5es<\/h1>\n\n\n\n![\"Revolu\u00e7\u00e3o](\"https:\/\/fee.org\/media\/33425\/screen-shot-2019-04-02-at-10951-pm.png?anchor=center&mode=crop&width=1200&rnd=132017178740000000\")
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Agora que estamos no “\u00faltimo andar” \u00e9 muito importante que voc\u00ea tenha em mente o objetivo de que configura\u00e7\u00f5es devem ser externas ao seu c\u00f3digo fonte<\/strong>. Desde o seu lan\u00e7amento uma das principais features do Spring Boot foi o fato de ter “configura\u00e7\u00f5es externaliz\u00e1veis”<\/a>. A ideia \u00e9 simples: h\u00e1 um \u00fanico pacote da sua aplica\u00e7\u00e3o que ser\u00e1 implantado em diversos ambientes, cada qual com o seu pr\u00f3prio conjunto de configura\u00e7\u00f5es.<\/p>\n\n\n\nUm dos objetivos do Spring Boot \u00e9 que voc\u00ea tenha um conjunto de configura\u00e7\u00f5es padr\u00e3o para executar a sua aplica\u00e7\u00e3o, mas que possam ser alteradas de acordo com o ambiente no qual o projeto \u00e9 executado. Sendo assim voc\u00ea teria, por exemplo, configura\u00e7\u00f5es \u00fanicas para acesso a banco de dados no ambiente de produ\u00e7\u00e3o, teste, homologa\u00e7\u00e3o, desenvolvimento, etc.<\/p>\n\n\n\n
Ordem de carregamento<\/h2>\n\n\n\n
Na documenta\u00e7\u00e3o oficial do Spring Boot voc\u00ea encontra este link<\/a> que descreve as 14 fontes usadas pelo Spring Boot na busca por configura\u00e7\u00f5es (properties). A ideia \u00e9 fornecer ao desenvolvedor (ou equipe de opera\u00e7\u00e3o) um mecanismo que permita sobrescrever de forma f\u00e1cil praticamente qualquer configura\u00e7\u00e3o usada pela sua aplica\u00e7\u00e3o.<\/p>\n\n\n\nVoc\u00ea pode ver a lista das 14 fontes no link que mencionei acima, mas vou copi\u00e1-la para c\u00e1 pois a usaremos para entender o funcionamento:<\/p>\n\n\n\n
- Configura\u00e7\u00f5es padr\u00e3o do framework.<\/li>
- As configura\u00e7\u00f5es que voc\u00ea define com a anota\u00e7\u00e3o @PropertySource<\/li>
- Arquivos de configura\u00e7\u00e3o (o famigerado application.data)<\/li>
- RandomValuePropertySource – um recurso do Spring Boot que permite inserir valores rand\u00f4micos em propriedades.<\/li>
- Vari\u00e1veis de ambiente do sistema operacional<\/li>
- Propriedades do sistema (as System Properties)<\/li>
- Via JNDI buscando em java:comp\/env (t\u00e1 a\u00ed um recurso pouco usado do Java e que \u00e9 bem \u00fatil, viu?)<\/li>
- Init params do ServletContext (em aplica\u00e7\u00f5es web)<\/li>
- Par\u00e2metros do ServletConfig. <\/li>
- Propriedades definidas na vari\u00e1vel de ambiente SPRING_APPLICATION_JSON (merece um post a parte este recurso, n\u00e3o inclu\u00ed neste post por que quis me ater apenas aos recursos mais usados)<\/li>
- Par\u00e2metros de linha de comando<\/li>
- Atributos properties nos testes.<\/li>
- @TestPropertySource – voc\u00ea inclui esta anota\u00e7\u00e3o nos seus testes automatizados com Spring.<\/li>
- Arquivo de configura\u00e7\u00f5es globais do Devtools (novamente, merece um post a parte este recurso, mas n\u00e3o o inclu\u00ed neste post para que seja poss\u00edvel nos ater apenas aos usos mais comuns)<\/li><\/ol>\n\n\n\n
Muita confus\u00e3o<\/strong> surge a partir desta ordem de carregamento, ent\u00e3o vamos a um exemplo. Imagine que temos o seguinte arquivo “application.properties” (falaremos mais sobre este arquivo e suas variantes adiante, contenha sua ansiedade) no seu projeto:<\/p>\n\n\n\nnome=Kico
sobrenome=Lobo<\/pre>\n\n\n\nSe sua aplica\u00e7\u00e3o for compilada e executada sem quaisquer informa\u00e7\u00e3o adicional (java -jar Aplicacao.jar) os valores definidos neste arquivo ser\u00e3o mantidos (item 3). Sempre o Spring Boot verifica todos os elementos da lista ao executar a aplica\u00e7\u00e3o, sendo assim vamos continuar no exemplo para que a coisa fique mais simples, pois h\u00e1 uma pegadinha envolvendo algo sobre o qual falei no in\u00edcio deste post.<\/p>\n\n\n\n
Se houver uma vari\u00e1vel de ambiente chamada “nome” com o valor “Nanna”, teremos aqui o valor “Nanna” aplicado na configura\u00e7\u00e3o (item 5, posterior ao 3).<\/p>\n\n\n\n
Se for passada a propriedade de sistema nome via par\u00e2metro (“-Dnome=Juca”) para a aplica\u00e7\u00e3o, o valor ser\u00e1 “Juca” (item 6, posterior ao 5 e 3). Sendo assim voc\u00ea pode sobrescrever vari\u00e1veis de ambiente na execu\u00e7\u00e3o do seu projeto tamb\u00e9m.<\/p>\n\n\n\n
At\u00e9 chegarmos ao item 11: “par\u00e2metros de linha de comando”. Aqui o Spring Boot reconhece o valor de vari\u00e1veis da seguinte forma: “–nome=Jucolino”. Sendo assim, se defini a vari\u00e1vel nome no arquivo (item 3), tamb\u00e9m uma vari\u00e1vel de ambiente com mesmo nome (item 5), mesmo assim ainda fui l\u00e1 e coloquei uma propriedade de sistema (item 6), se eu incluir um “–nome=JucolinoBruto” por linha de comando, prevalece o item 11 (em teoria).<\/p>\n\n\n\n
Via de regra: as fontes de configura\u00e7\u00e3o que tenham ordem maior s\u00e3o as que ser\u00e3o carregadas pelo seu projeto durante a inicializa\u00e7\u00e3o.<\/p>\n\n\n\n
Arquivos de configura\u00e7\u00e3o<\/h2>\n\n\n\n
Muito cuidado com o item 3 da lista acima: arquivos de configura\u00e7\u00e3o. Aqui reside boa parte dos problemas que vejo as pessoas enfrentarem em seu dia a dia. Isto por que estes arquivos se dividem em duas categorias:<\/p>\n\n\n\n
- application.properties definido para o perfil padr\u00e3o<\/li>
- application-[perfil].properties para os arquivos que n\u00e3o s\u00e3o o perfil padr\u00e3o. Exemplo: arquivo application-dev.properties para o perfil “dev”, application-prod.properties para o perfil “prod”.<\/li><\/ul>\n\n\n\n
O Spring Boot, tal como descrito em sua documenta\u00e7\u00e3o<\/a>, carrega estes arquivos na seguinte ordem:<\/p>\n\n\n\n- Arquivo application.properties embarcado na aplica\u00e7\u00e3o (classpath) para o perfil padr\u00e3o.<\/li>
- Arquivo application-[perfil].properties para perfis espec\u00edficos (exemplo: application-dev.properties para o perfil dev) embarcados no projeto.<\/li>
- Arquivo application.properties externo<\/strong> ao seu projeto. <\/li>
- Arquivo application-[perfil].properties externo <\/strong>ao seu projeto.<\/li><\/ol>\n\n\n\n
Sendo assim, imagine que eu tenha o arquivo application.properties embarcado em meu projeto com o seguinte conte\u00fado:<\/p>\n\n\n\n
server.port=8080<\/pre>\n\n\n\nEsta propriedade define a porta do servi\u00e7o que identificar\u00e1 minha aplica\u00e7\u00e3o. Se for ativado o perfil “dev” no projeto, e existir internamente um arquivo chamado “application-dev.properties”, e neste o valor da propriedade “server.port” for “9090”, o valor usado pela aplica\u00e7\u00e3o ser\u00e1 o “9090”.<\/p>\n\n\n\n
Mas e se eu ativar mais de um perfil na minha aplica\u00e7\u00e3o, digamos, “dev,qa”. Os arquivos nos quais a chave ser\u00e1 buscada no classpath ser\u00e1:<\/p>\n\n\n\n
- application.properties<\/li>
- application-dev.properties<\/li>
- application-qa.properties (observe: os arquivos de perfil s\u00e3o carregados na ordem em que s\u00e3o declarados pela propriedade spring.profiles.active)<\/li><\/ol>\n\n\n\n
Se no mesmo exemplo a propriedade “server.port” estiver definida tamb\u00e9m no arquivo “application-qa.properties” com valor “1234”, “1234” ser\u00e1 o valor da propriedade no final.<\/p>\n\n\n\n
<\/figure>\n\n\n\n<\/p>\n\n\n\n
Sabe aonde mora a maior parte das d\u00favidas relativas a este tema? Aus\u00eancia de conhecimento conceitual. Vamos dar nomes \u00e0s coisas aqui pra tornar nossa vida mais f\u00e1cil. Iremos percorrer tr\u00eas andares deste edif\u00edcio conceitual para que voc\u00ea possa ver desde os pontos mais elementares at\u00e9 os mais abstratos.<\/p>\n\n\n\n
Primeiro andar: Java<\/h2>\n\n\n\n<\/figure><\/div>\n\n\n\nEm Java voc\u00ea tem diversas fontes para suas configura\u00e7\u00f5es: arquivos de prorpriedades (properties), vari\u00e1veis de ambiente, vari\u00e1veis de sistema… Responda rapidamente, olhando o Javadoc da classe java.lang.System, voc\u00ea consegue explicar de forma imediata a diferen\u00e7a entre os m\u00e9todos getenv() e getProperty()?<\/p>\n\n\n\n<\/figure>\n\n\n\nO nome dos m\u00e9todos j\u00e1 inicia uma pequena confus\u00e3o: por que “getenv” e n\u00e3o “getEnv”? O primeiro conceito ent\u00e3o a tratar ser\u00e1 a diferen\u00e7a entre “environment variable” (vari\u00e1vel de ambiente) e “system property” (propriedade do sistema). <\/p>\n\n\n\n
Vari\u00e1veis de ambiente<\/h3>\n\n\n\n
Vari\u00e1vel de ambiente \u00e9 aquela que voc\u00ea define no sistema operacional em que seu c\u00f3digo \u00e9 executado. No caso do Linux (e macOS) o fazemos com os comandos set e export<\/a>. J\u00e1 no caso do Windows \u00e9 com o comando set (mais comum) ou a partir do utilit\u00e1rio de configura\u00e7\u00e3o gr\u00e1fica de ambiente, tal como na imagem abaixo:<\/p>\n\n\n\n<\/figure><\/div>\n\n\n\nVamos ent\u00e3o a um exemplo bem simples: imagine que estou no Linux e usando o comando export eu defina a vari\u00e1vel de ambiente nome<\/em> com o valor Kico<\/em>, tal como no script a seguir:<\/p>\n\n\n\nexport nome=Kico<\/pre>\n\n\n\nE na sequ\u00eancia eu tenha o seguinte c\u00f3digo Java:<\/p>\n\n\n\n
System.out.println(System.getenv(\"nome\");<\/pre>\n\n\n\nA sa\u00edda ser\u00e1…<\/p>\n\n\n\n
Kico<\/pre>\n\n\n\nResumindo: temos aqui vari\u00e1veis do sistema operacional que s\u00e3o completamente externas ao nosso c\u00f3digo.<\/em><\/strong> Quer ser aprofundar no tema envolvendo Java? Este \u00e9 o link<\/a>.<\/p>\n\n\n\nPropriedades do sistema<\/h3>\n\n\n\n
Aqui mora a confus\u00e3o. Propriedades do sistema (System Properties) s\u00e3o configura\u00e7\u00f5es que toda aplica\u00e7\u00e3o Java mant\u00e9m em mem\u00f3ria que dizem respeito ao seu ambiente de execu\u00e7\u00e3o. Algumas destas propriedades s\u00e3o padr\u00e3o como, por exemplo, “user.home”, que diz qual o diret\u00f3rio home do usu\u00e1rio, “os.name”, que diz qual o sistema operacional no qual a aplica\u00e7\u00e3o est\u00e1 sendo executada, etc.<\/p>\n\n\n\n
Estas propriedades s\u00e3o portanto impl\u00edcitas (como as que mencionei acima) ou expl\u00edcitas. As expl\u00edcitas s\u00e3o aquelas que passamos para o comando java usando argumentos que come\u00e7am com “-D”. Imagine que eu tenha um programa Java tal como o apresentado a seguir:<\/p>\n\n\n\n
public class Programa {\n public static void main(String args[]) {\n System.out.println(System.getProperty(\"nome\"));\n }\n}<\/code><\/pre>\n\n\n\nCompilado meu programa, e executando-o com o comando abaixo, a sa\u00edda ser\u00e1 “Kico”<\/p>\n\n\n\n
java -Dnome=Kico<\/strong> Programa<\/pre>\n\n\n\nEnt\u00e3o, simplificando, as propriedades do sistema s\u00e3o as impl\u00edcitas da plataforma de execu\u00e7\u00e3o e aquelas que passamos por linha de comando ao nosso programa Java<\/strong>. Quer se aprofundar no assunto e conhecer as propriedades padr\u00e3o? Este \u00e9 o link<\/a>.<\/p>\n\n\n\nSegundo andar: Spring<\/h2>\n\n\n\n<\/figure><\/div>\n\n\n\nPropriedades (Properties)<\/h3>\n\n\n\n
Do ponto de vista de quem usa o Spring n\u00e3o h\u00e1 vari\u00e1veis de ambiente ou propriedades do sistema, h\u00e1 apenas propriedades (Properties)<\/strong>. Uma propriedade \u00e9 uma informa\u00e7\u00e3o de configura\u00e7\u00e3o no formato chave\/valor. Toda propriedade portanto \u00e9 identificada por uma chave e possui um valor associado a esta.<\/p>\n\n\n\nPense no conceito de property (usarei o termo em ingl\u00eas daqui pra frente pois \u00e9 o que voc\u00ea encontrar\u00e1 na esmagadora maioria das documenta\u00e7\u00f5es e literatura relacionada) como a unidade mais fundamental de configura\u00e7\u00e3o no Spring. O objetivo das abstra\u00e7\u00f5es sobre as quais falarei a respeito agora tem como objetivo obter estas informa\u00e7\u00f5es e organiz\u00e1-las para voc\u00ea.<\/p>\n\n\n\n
Environment (Ambiente)<\/h3>\n\n\n\n
Esta abstra\u00e7\u00e3o consiste em uma interface<\/a> do container Spring que ser\u00e1 usada para modelar outro aspecto fundamental do framework: os perfis (profiles). Antes de falarmos sobre esta outra abstra\u00e7\u00e3o \u00e9 importante refletir um pouco sobre o que v\u00eam a ser um Environment.<\/p>\n\n\n\nO Environment representa na pr\u00e1tica o ambiente de execu\u00e7\u00e3o da sua aplica\u00e7\u00e3o. \u00c9 ele que diz quais vari\u00e1veis de ambiente estamos usando, quais beans dever\u00e3o ser instanciados e tamb\u00e9m quais os perfis que est\u00e3o ativos ou que ser\u00e3o ativados pela nossa aplica\u00e7\u00e3o. Antes de falar sobre os perfis \u00e9 importante mencionar um elemento bastante usado por este componente: a property source<\/em>.<\/p>\n\n\n\nProperty Source<\/h3>\n\n\n\n
Sua fun\u00e7\u00e3o consiste em representar uma fonte de dados da qual iremos obter nossas listas de propriedades. Esta fonte de dados pode ser literalmente qualquer coisa: arquivos, web services, bancos de dados, sistemas gestores de configura\u00e7\u00e3o como o Spring Cloud Config Server<\/a>, etc.<\/p>\n\n\n\nEm aplica\u00e7\u00f5es Spring Boot quando desejamos externalizar o acesso aos arquivos de configura\u00e7\u00e3o usamos a anota\u00e7\u00e3o @PropertySource<\/a> tal como no exemplo a seguir:<\/p>\n\n\n\n@PropertySource(\"file:\/\/\/home\/kicolobo\/configsfelizes.properties\")<\/strong>\npublic class AplicacaoSpringBoot {\n ...\n}<\/pre>\n\n\n\nE, claro, caso nenhuma das op\u00e7\u00f5es providas pelo framework n\u00e3o lhe atendam, basta que voc\u00ea implemente o seu pr\u00f3prio Property Source e registrando-o no Spring, o que foge do assunto deste post.<\/p>\n\n\n\n
Profiles (Perfis) – muita aten\u00e7\u00e3o aqui!<\/strong><\/h3>\n\n\n\n<\/figure><\/div>\n\n\n\nUma aplica\u00e7\u00e3o Spring Boot ao ser executada pode ter n perfis, mas o que \u00e9 um perfil? O profile identifica um conjunto de configura\u00e7\u00f5es que definem como a sua aplica\u00e7\u00e3o deve se portar em um dado ambiente de execu\u00e7\u00e3o. \u00c9 muito importante aqui saber a diferen\u00e7a entre profiles e ambientes de execu\u00e7\u00e3o, pois muitas vezes estes s\u00e3o usados de modo intercambi\u00e1vel:<\/p>\n\n\n\n
- Ambiente de execu\u00e7\u00e3o<\/strong> – onde sua aplica\u00e7\u00e3o est\u00e1 sendo executada. Exemplo: ambiente de desenvolvimento, execu\u00e7\u00e3o de testes, produ\u00e7\u00e3o, homologa\u00e7\u00e3o, etc.<\/li>
- Profile (Perfil)<\/strong> – um conjunto l\u00f3gico de configura\u00e7\u00f5es que define como sua aplica\u00e7\u00e3o ir\u00e1 ser executada.<\/strong><\/li><\/ul>\n\n\n\n
Ent\u00e3o voc\u00ea pode, por exemplo, ter perfis que identifiquem o tipo de persist\u00eancia que seu projeto est\u00e1 usando. Exemplo<\/strong>: um perfil chamado Relacional<\/em> que indica que estamos usando datasources contra uma base de dados relacional e outro chamado NoSQL<\/em> que indica que estamos usando bases de dados n\u00e3o relacionais.<\/p>\n\n\n\nE voc\u00ea pode ter este mesmo perfil aplicado a diferentes ambientes de execu\u00e7\u00e3o: imagine o perfil NoSQL<\/em> aplicado aos ambientes de Produ\u00e7\u00e3o e Desenvolvimento, enquanto o perfil Relacional<\/em> apenas no ambiente de homologa\u00e7\u00e3o.<\/p>\n\n\n\nVoltando ao exemplo dos profiles NoSQL<\/em> e Relacional<\/em>, \u00e9 fundamental saber<\/strong> que o Profile n\u00e3o indica apenas o conjunto de propriedades (properties<\/em>) que ir\u00e3o ser carregadas, mas tamb\u00e9m quais beans<\/em> ser\u00e3o instanciados<\/strong>. Voltando ao exemplo, podemos ter configura\u00e7\u00f5es de DAO implementadas tal como no exemplo a seguir:<\/p>\n\n\n\n@Configuration<\/strong>\npublic class ConfiguracaoDAO {\n @Bean @Profile(\"Relacional\")<\/strong>\n public DAOUsuario getDAORelacional() {\n return new DAOUsuarioMySQL();\n }\n\n @Bean @Profile(\"NoSQL\")<\/strong>\n public DAOUsuario getDAONaoRelacional() {\n return new DAOUsuarioMongoDB()\n }\n}<\/pre>\n\n\n\nProgramando contra interfaces a classe cliente nem sonha que DAOUsuario<\/em> \u00e9 usado contra o MongoDB ou MySQL, mantemos assim a boa pr\u00e1tica de programar contra interfaces e n\u00e3o implementa\u00e7\u00f5es.<\/p>\n\n\n\nMas a\u00ed voc\u00ea me pergunta: como eu defino o profile adotado?<\/p>\n\n\n\n
Selecionando os profiles<\/h4>\n\n\n\nPor system property<\/h5>\n\n\n\n
\u00c9 f\u00e1cil, e aqui entra aqueles pontos que voc\u00ea deve decorar<\/strong>. Primeiro a forma mais simples, que \u00e9 a partir da linha de comando: voc\u00ea usa a system property<\/strong> spring.profiles.active<\/em>. Vamos a um exemplo:<\/p>\n\n\n\njava -Dspring.profiles.active=prod AplicacaoLinda.jar<\/pre>\n\n\n\nDefinimos que nossa aplica\u00e7\u00e3o ir\u00e1 executar usando o profile prod<\/em>. E se eu quiser usar mais de um profile ao mesmo tempo? E se eu quiser usar os profiles prod e relacional? Separe com v\u00edrgulas:<\/p>\n\n\n\njava -Dspring.profiles.active=prod,relacional AplicacaoSuperPoderosa.jar<\/pre>\n\n\n\nMas h\u00e1 outras maneiras: voc\u00ea pode definir o profile por arquivos de configura\u00e7\u00e3o, Maven, em tempo de execu\u00e7\u00e3o e outros. Este link aqui<\/a> pode te ensinar estas outras maneiras.<\/p>\n\n\n\n<\/figure><\/div>\n\n\n\nSe eu n\u00e3o selecionar um profile, que profile \u00e9 carregado?<\/strong> <\/strong>O profile default<\/strong>. Importante que voc\u00ea tenha esta informa\u00e7\u00e3o em mente. No Spring Boot n\u00e3o existem profiles como dev, prod, test<\/em> por padr\u00e3o, mas como vemos em diversos posts, acabamos por achar que eles existem no framework.<\/p>\n\n\n\n<\/p>\n\n\n\n
Programaticamente <\/h5>\n\n\n\n
Antes da aplica\u00e7\u00e3o ser iniciada, no m\u00e9todo main, voc\u00ea pode usar o m\u00e9todo setAdditionalProfiles<\/em> da classe SpringApplication<\/em>. Importante voc\u00ea saber que ap\u00f3s a aplica\u00e7\u00e3o ter sido iniciada n\u00e3o \u00e9 mais poss\u00edvel trocar o perfil (at\u00e9 onde sei). Mais detalhes sobre os perfis do Spring Boot neste link<\/a>.<\/p>\n\n\n\nTerceiro andar: Spring Boot e suas auto configura\u00e7\u00f5es<\/h2>\n\n\n\n<\/figure><\/div>\n\n\n\nCalma, \u00e9 o \u00faltimo andar MESMO agora (por enquanto, pois n\u00e3o vou falar aqui do Spring Cloud). O Spring Boot adiciona mais uma abstra\u00e7\u00e3o importante referente a configura\u00e7\u00f5es: as auto configura\u00e7\u00f5es.<\/strong><\/p>\n\n\n\nMuita gente ignora este aspecto do “Boot”: o framework \u00e9 composto por diversos m\u00f3dulos que voc\u00ea pode adicionar ao seu projeto, identificados no Maven\/Gradle com o nome “spring-boot-starter-*”, e cada um destes m\u00f3dulos cont\u00e9m, al\u00e9m das suas pr\u00f3prias funcionalidades, suas pr\u00f3prias configura\u00e7\u00f5es (auto configura\u00e7\u00f5es), ativadas no momento em que a aplica\u00e7\u00e3o \u00e9 iniciada.<\/p>\n\n\n\n
\u00c9 fundamental que voc\u00ea saiba disto<\/strong> por que temos aqui aplicado o conceito de conven\u00e7\u00f5es sobre configura\u00e7\u00e3o. O autor do m\u00f3dulo define qual ser\u00e1 o seu comportamento padr\u00e3o e cabe a voc\u00ea customizar o que \u00e9 necess\u00e1rio para o seu projeto.<\/strong> Mas a\u00ed entra a seguinte quest\u00e3o: como saber quais s\u00e3o estas configura\u00e7\u00f5es? Simples: voc\u00ea executa sua aplica\u00e7\u00e3o com o par\u00e2metro –debug e todas ser\u00e3o impressas no console. Exemplo:<\/p>\n\n\n\njava --debug -jar AplicacaoLinda.jar<\/pre>\n\n\n\nE se eu estiver usando Maven ou Gradle no meu ambiente de desenvolvimento? D\u00e1 pra passar o par\u00e2metro tamb\u00e9m.<\/p>\n\n\n\n
Sendo assim se voc\u00ea usa, por exemplo, o m\u00f3dulo JPA do Spring Boot: spring-boot-starter-jpa<\/em>, automaticamente \u00e9 configurado um datasource para voc\u00ea. E estas configura\u00e7\u00f5es variam de m\u00f3dulo para m\u00f3dulo, mas n\u00e3o fique triste. Mas como estas configura\u00e7\u00f5es s\u00e3o carregadas e onde est\u00e3o?<\/p>\n\n\n\nNo momento em que a aplica\u00e7\u00e3o \u00e9 iniciada o Spring varre todos os arquivos JAR presentes no seu classpath que perten\u00e7am a estes m\u00f3dulos. E em cada um destes busca por um arquivo chamado spring.factories<\/em>, presente no diret\u00f3rio META-INF<\/em> do JAR. Neste arquivo est\u00e3o listadas as classes de configura\u00e7\u00e3o (@Configuration) que s\u00e3o as respons\u00e1veis por configurar aquele m\u00f3dulo.<\/p>\n\n\n\nDica<\/strong>: leia este t\u00f3pico<\/a> da documenta\u00e7\u00e3o oficial do Spring Boot para entender como estes m\u00f3dulos s\u00e3o escritos.<\/p>\n\n\n\nCarregando configura\u00e7\u00f5es<\/h1>\n\n\n\n<\/figure>\n\n\n\n<\/p>\n\n\n\n
Agora que estamos no “\u00faltimo andar” \u00e9 muito importante que voc\u00ea tenha em mente o objetivo de que configura\u00e7\u00f5es devem ser externas ao seu c\u00f3digo fonte<\/strong>. Desde o seu lan\u00e7amento uma das principais features do Spring Boot foi o fato de ter “configura\u00e7\u00f5es externaliz\u00e1veis”<\/a>. A ideia \u00e9 simples: h\u00e1 um \u00fanico pacote da sua aplica\u00e7\u00e3o que ser\u00e1 implantado em diversos ambientes, cada qual com o seu pr\u00f3prio conjunto de configura\u00e7\u00f5es.<\/p>\n\n\n\nUm dos objetivos do Spring Boot \u00e9 que voc\u00ea tenha um conjunto de configura\u00e7\u00f5es padr\u00e3o para executar a sua aplica\u00e7\u00e3o, mas que possam ser alteradas de acordo com o ambiente no qual o projeto \u00e9 executado. Sendo assim voc\u00ea teria, por exemplo, configura\u00e7\u00f5es \u00fanicas para acesso a banco de dados no ambiente de produ\u00e7\u00e3o, teste, homologa\u00e7\u00e3o, desenvolvimento, etc.<\/p>\n\n\n\n
Ordem de carregamento<\/h2>\n\n\n\n
Na documenta\u00e7\u00e3o oficial do Spring Boot voc\u00ea encontra este link<\/a> que descreve as 14 fontes usadas pelo Spring Boot na busca por configura\u00e7\u00f5es (properties). A ideia \u00e9 fornecer ao desenvolvedor (ou equipe de opera\u00e7\u00e3o) um mecanismo que permita sobrescrever de forma f\u00e1cil praticamente qualquer configura\u00e7\u00e3o usada pela sua aplica\u00e7\u00e3o.<\/p>\n\n\n\nVoc\u00ea pode ver a lista das 14 fontes no link que mencionei acima, mas vou copi\u00e1-la para c\u00e1 pois a usaremos para entender o funcionamento:<\/p>\n\n\n\n
- Configura\u00e7\u00f5es padr\u00e3o do framework.<\/li>
- As configura\u00e7\u00f5es que voc\u00ea define com a anota\u00e7\u00e3o @PropertySource<\/li>
- Arquivos de configura\u00e7\u00e3o (o famigerado application.data)<\/li>
- RandomValuePropertySource – um recurso do Spring Boot que permite inserir valores rand\u00f4micos em propriedades.<\/li>
- Vari\u00e1veis de ambiente do sistema operacional<\/li>
- Propriedades do sistema (as System Properties)<\/li>
- Via JNDI buscando em java:comp\/env (t\u00e1 a\u00ed um recurso pouco usado do Java e que \u00e9 bem \u00fatil, viu?)<\/li>
- Init params do ServletContext (em aplica\u00e7\u00f5es web)<\/li>
- Par\u00e2metros do ServletConfig. <\/li>
- Propriedades definidas na vari\u00e1vel de ambiente SPRING_APPLICATION_JSON (merece um post a parte este recurso, n\u00e3o inclu\u00ed neste post por que quis me ater apenas aos recursos mais usados)<\/li>
- Par\u00e2metros de linha de comando<\/li>
- Atributos properties nos testes.<\/li>
- @TestPropertySource – voc\u00ea inclui esta anota\u00e7\u00e3o nos seus testes automatizados com Spring.<\/li>
- Arquivo de configura\u00e7\u00f5es globais do Devtools (novamente, merece um post a parte este recurso, mas n\u00e3o o inclu\u00ed neste post para que seja poss\u00edvel nos ater apenas aos usos mais comuns)<\/li><\/ol>\n\n\n\n
Muita confus\u00e3o<\/strong> surge a partir desta ordem de carregamento, ent\u00e3o vamos a um exemplo. Imagine que temos o seguinte arquivo “application.properties” (falaremos mais sobre este arquivo e suas variantes adiante, contenha sua ansiedade) no seu projeto:<\/p>\n\n\n\nnome=Kico
sobrenome=Lobo<\/pre>\n\n\n\nSe sua aplica\u00e7\u00e3o for compilada e executada sem quaisquer informa\u00e7\u00e3o adicional (java -jar Aplicacao.jar) os valores definidos neste arquivo ser\u00e3o mantidos (item 3). Sempre o Spring Boot verifica todos os elementos da lista ao executar a aplica\u00e7\u00e3o, sendo assim vamos continuar no exemplo para que a coisa fique mais simples, pois h\u00e1 uma pegadinha envolvendo algo sobre o qual falei no in\u00edcio deste post.<\/p>\n\n\n\n
Se houver uma vari\u00e1vel de ambiente chamada “nome” com o valor “Nanna”, teremos aqui o valor “Nanna” aplicado na configura\u00e7\u00e3o (item 5, posterior ao 3).<\/p>\n\n\n\n
Se for passada a propriedade de sistema nome via par\u00e2metro (“-Dnome=Juca”) para a aplica\u00e7\u00e3o, o valor ser\u00e1 “Juca” (item 6, posterior ao 5 e 3). Sendo assim voc\u00ea pode sobrescrever vari\u00e1veis de ambiente na execu\u00e7\u00e3o do seu projeto tamb\u00e9m.<\/p>\n\n\n\n
At\u00e9 chegarmos ao item 11: “par\u00e2metros de linha de comando”. Aqui o Spring Boot reconhece o valor de vari\u00e1veis da seguinte forma: “–nome=Jucolino”. Sendo assim, se defini a vari\u00e1vel nome no arquivo (item 3), tamb\u00e9m uma vari\u00e1vel de ambiente com mesmo nome (item 5), mesmo assim ainda fui l\u00e1 e coloquei uma propriedade de sistema (item 6), se eu incluir um “–nome=JucolinoBruto” por linha de comando, prevalece o item 11 (em teoria).<\/p>\n\n\n\n
Via de regra: as fontes de configura\u00e7\u00e3o que tenham ordem maior s\u00e3o as que ser\u00e3o carregadas pelo seu projeto durante a inicializa\u00e7\u00e3o.<\/p>\n\n\n\n
Arquivos de configura\u00e7\u00e3o<\/h2>\n\n\n\n
Muito cuidado com o item 3 da lista acima: arquivos de configura\u00e7\u00e3o. Aqui reside boa parte dos problemas que vejo as pessoas enfrentarem em seu dia a dia. Isto por que estes arquivos se dividem em duas categorias:<\/p>\n\n\n\n
- application.properties definido para o perfil padr\u00e3o<\/li>
- application-[perfil].properties para os arquivos que n\u00e3o s\u00e3o o perfil padr\u00e3o. Exemplo: arquivo application-dev.properties para o perfil “dev”, application-prod.properties para o perfil “prod”.<\/li><\/ul>\n\n\n\n
O Spring Boot, tal como descrito em sua documenta\u00e7\u00e3o<\/a>, carrega estes arquivos na seguinte ordem:<\/p>\n\n\n\n- Arquivo application.properties embarcado na aplica\u00e7\u00e3o (classpath) para o perfil padr\u00e3o.<\/li>
- Arquivo application-[perfil].properties para perfis espec\u00edficos (exemplo: application-dev.properties para o perfil dev) embarcados no projeto.<\/li>
- Arquivo application.properties externo<\/strong> ao seu projeto. <\/li>
- Arquivo application-[perfil].properties externo <\/strong>ao seu projeto.<\/li><\/ol>\n\n\n\n
Sendo assim, imagine que eu tenha o arquivo application.properties embarcado em meu projeto com o seguinte conte\u00fado:<\/p>\n\n\n\n
server.port=8080<\/pre>\n\n\n\nEsta propriedade define a porta do servi\u00e7o que identificar\u00e1 minha aplica\u00e7\u00e3o. Se for ativado o perfil “dev” no projeto, e existir internamente um arquivo chamado “application-dev.properties”, e neste o valor da propriedade “server.port” for “9090”, o valor usado pela aplica\u00e7\u00e3o ser\u00e1 o “9090”.<\/p>\n\n\n\n
Mas e se eu ativar mais de um perfil na minha aplica\u00e7\u00e3o, digamos, “dev,qa”. Os arquivos nos quais a chave ser\u00e1 buscada no classpath ser\u00e1:<\/p>\n\n\n\n
- application.properties<\/li>
- application-dev.properties<\/li>
- application-qa.properties (observe: os arquivos de perfil s\u00e3o carregados na ordem em que s\u00e3o declarados pela propriedade spring.profiles.active)<\/li><\/ol>\n\n\n\n
Se no mesmo exemplo a propriedade “server.port” estiver definida tamb\u00e9m no arquivo “application-qa.properties” com valor “1234”, “1234” ser\u00e1 o valor da propriedade no final.<\/p>\n\n\n\n
<\/figure><\/div>\n\n\n\nEm Java voc\u00ea tem diversas fontes para suas configura\u00e7\u00f5es: arquivos de prorpriedades (properties), vari\u00e1veis de ambiente, vari\u00e1veis de sistema… Responda rapidamente, olhando o Javadoc da classe java.lang.System, voc\u00ea consegue explicar de forma imediata a diferen\u00e7a entre os m\u00e9todos getenv() e getProperty()?<\/p>\n\n\n\n O nome dos m\u00e9todos j\u00e1 inicia uma pequena confus\u00e3o: por que “getenv” e n\u00e3o “getEnv”? O primeiro conceito ent\u00e3o a tratar ser\u00e1 a diferen\u00e7a entre “environment variable” (vari\u00e1vel de ambiente) e “system property” (propriedade do sistema). <\/p>\n\n\n\n Vari\u00e1vel de ambiente \u00e9 aquela que voc\u00ea define no sistema operacional em que seu c\u00f3digo \u00e9 executado. No caso do Linux (e macOS) o fazemos com os comandos set e export<\/a>. J\u00e1 no caso do Windows \u00e9 com o comando set (mais comum) ou a partir do utilit\u00e1rio de configura\u00e7\u00e3o gr\u00e1fica de ambiente, tal como na imagem abaixo:<\/p>\n\n\n\n Vamos ent\u00e3o a um exemplo bem simples: imagine que estou no Linux e usando o comando export eu defina a vari\u00e1vel de ambiente nome<\/em> com o valor Kico<\/em>, tal como no script a seguir:<\/p>\n\n\n\n E na sequ\u00eancia eu tenha o seguinte c\u00f3digo Java:<\/p>\n\n\n\n A sa\u00edda ser\u00e1…<\/p>\n\n\n\n Resumindo: temos aqui vari\u00e1veis do sistema operacional que s\u00e3o completamente externas ao nosso c\u00f3digo.<\/em><\/strong> Quer ser aprofundar no tema envolvendo Java? Este \u00e9 o link<\/a>.<\/p>\n\n\n\n Aqui mora a confus\u00e3o. Propriedades do sistema (System Properties) s\u00e3o configura\u00e7\u00f5es que toda aplica\u00e7\u00e3o Java mant\u00e9m em mem\u00f3ria que dizem respeito ao seu ambiente de execu\u00e7\u00e3o. Algumas destas propriedades s\u00e3o padr\u00e3o como, por exemplo, “user.home”, que diz qual o diret\u00f3rio home do usu\u00e1rio, “os.name”, que diz qual o sistema operacional no qual a aplica\u00e7\u00e3o est\u00e1 sendo executada, etc.<\/p>\n\n\n\n Estas propriedades s\u00e3o portanto impl\u00edcitas (como as que mencionei acima) ou expl\u00edcitas. As expl\u00edcitas s\u00e3o aquelas que passamos para o comando java usando argumentos que come\u00e7am com “-D”. Imagine que eu tenha um programa Java tal como o apresentado a seguir:<\/p>\n\n\n\n Compilado meu programa, e executando-o com o comando abaixo, a sa\u00edda ser\u00e1 “Kico”<\/p>\n\n\n\n Ent\u00e3o, simplificando, as propriedades do sistema s\u00e3o as impl\u00edcitas da plataforma de execu\u00e7\u00e3o e aquelas que passamos por linha de comando ao nosso programa Java<\/strong>. Quer se aprofundar no assunto e conhecer as propriedades padr\u00e3o? Este \u00e9 o link<\/a>.<\/p>\n\n\n\n Do ponto de vista de quem usa o Spring n\u00e3o h\u00e1 vari\u00e1veis de ambiente ou propriedades do sistema, h\u00e1 apenas propriedades (Properties)<\/strong>. Uma propriedade \u00e9 uma informa\u00e7\u00e3o de configura\u00e7\u00e3o no formato chave\/valor. Toda propriedade portanto \u00e9 identificada por uma chave e possui um valor associado a esta.<\/p>\n\n\n\n Pense no conceito de property (usarei o termo em ingl\u00eas daqui pra frente pois \u00e9 o que voc\u00ea encontrar\u00e1 na esmagadora maioria das documenta\u00e7\u00f5es e literatura relacionada) como a unidade mais fundamental de configura\u00e7\u00e3o no Spring. O objetivo das abstra\u00e7\u00f5es sobre as quais falarei a respeito agora tem como objetivo obter estas informa\u00e7\u00f5es e organiz\u00e1-las para voc\u00ea.<\/p>\n\n\n\n Esta abstra\u00e7\u00e3o consiste em uma interface<\/a> do container Spring que ser\u00e1 usada para modelar outro aspecto fundamental do framework: os perfis (profiles). Antes de falarmos sobre esta outra abstra\u00e7\u00e3o \u00e9 importante refletir um pouco sobre o que v\u00eam a ser um Environment.<\/p>\n\n\n\n O Environment representa na pr\u00e1tica o ambiente de execu\u00e7\u00e3o da sua aplica\u00e7\u00e3o. \u00c9 ele que diz quais vari\u00e1veis de ambiente estamos usando, quais beans dever\u00e3o ser instanciados e tamb\u00e9m quais os perfis que est\u00e3o ativos ou que ser\u00e3o ativados pela nossa aplica\u00e7\u00e3o. Antes de falar sobre os perfis \u00e9 importante mencionar um elemento bastante usado por este componente: a property source<\/em>.<\/p>\n\n\n\n Sua fun\u00e7\u00e3o consiste em representar uma fonte de dados da qual iremos obter nossas listas de propriedades. Esta fonte de dados pode ser literalmente qualquer coisa: arquivos, web services, bancos de dados, sistemas gestores de configura\u00e7\u00e3o como o Spring Cloud Config Server<\/a>, etc.<\/p>\n\n\n\n Em aplica\u00e7\u00f5es Spring Boot quando desejamos externalizar o acesso aos arquivos de configura\u00e7\u00e3o usamos a anota\u00e7\u00e3o @PropertySource<\/a> tal como no exemplo a seguir:<\/p>\n\n\n\n E, claro, caso nenhuma das op\u00e7\u00f5es providas pelo framework n\u00e3o lhe atendam, basta que voc\u00ea implemente o seu pr\u00f3prio Property Source e registrando-o no Spring, o que foge do assunto deste post.<\/p>\n\n\n\n Uma aplica\u00e7\u00e3o Spring Boot ao ser executada pode ter n perfis, mas o que \u00e9 um perfil? O profile identifica um conjunto de configura\u00e7\u00f5es que definem como a sua aplica\u00e7\u00e3o deve se portar em um dado ambiente de execu\u00e7\u00e3o. \u00c9 muito importante aqui saber a diferen\u00e7a entre profiles e ambientes de execu\u00e7\u00e3o, pois muitas vezes estes s\u00e3o usados de modo intercambi\u00e1vel:<\/p>\n\n\n\n Ent\u00e3o voc\u00ea pode, por exemplo, ter perfis que identifiquem o tipo de persist\u00eancia que seu projeto est\u00e1 usando. Exemplo<\/strong>: um perfil chamado Relacional<\/em> que indica que estamos usando datasources contra uma base de dados relacional e outro chamado NoSQL<\/em> que indica que estamos usando bases de dados n\u00e3o relacionais.<\/p>\n\n\n\n E voc\u00ea pode ter este mesmo perfil aplicado a diferentes ambientes de execu\u00e7\u00e3o: imagine o perfil NoSQL<\/em> aplicado aos ambientes de Produ\u00e7\u00e3o e Desenvolvimento, enquanto o perfil Relacional<\/em> apenas no ambiente de homologa\u00e7\u00e3o.<\/p>\n\n\n\n Voltando ao exemplo dos profiles NoSQL<\/em> e Relacional<\/em>, \u00e9 fundamental saber<\/strong> que o Profile n\u00e3o indica apenas o conjunto de propriedades (properties<\/em>) que ir\u00e3o ser carregadas, mas tamb\u00e9m quais beans<\/em> ser\u00e3o instanciados<\/strong>. Voltando ao exemplo, podemos ter configura\u00e7\u00f5es de DAO implementadas tal como no exemplo a seguir:<\/p>\n\n\n\n Programando contra interfaces a classe cliente nem sonha que DAOUsuario<\/em> \u00e9 usado contra o MongoDB ou MySQL, mantemos assim a boa pr\u00e1tica de programar contra interfaces e n\u00e3o implementa\u00e7\u00f5es.<\/p>\n\n\n\n Mas a\u00ed voc\u00ea me pergunta: como eu defino o profile adotado?<\/p>\n\n\n\n \u00c9 f\u00e1cil, e aqui entra aqueles pontos que voc\u00ea deve decorar<\/strong>. Primeiro a forma mais simples, que \u00e9 a partir da linha de comando: voc\u00ea usa a system property<\/strong> spring.profiles.active<\/em>. Vamos a um exemplo:<\/p>\n\n\n\n Definimos que nossa aplica\u00e7\u00e3o ir\u00e1 executar usando o profile prod<\/em>. E se eu quiser usar mais de um profile ao mesmo tempo? E se eu quiser usar os profiles prod e relacional? Separe com v\u00edrgulas:<\/p>\n\n\n\n Mas h\u00e1 outras maneiras: voc\u00ea pode definir o profile por arquivos de configura\u00e7\u00e3o, Maven, em tempo de execu\u00e7\u00e3o e outros. Este link aqui<\/a> pode te ensinar estas outras maneiras.<\/p>\n\n\n\n Se eu n\u00e3o selecionar um profile, que profile \u00e9 carregado?<\/strong> <\/strong>O profile default<\/strong>. Importante que voc\u00ea tenha esta informa\u00e7\u00e3o em mente. No Spring Boot n\u00e3o existem profiles como dev, prod, test<\/em> por padr\u00e3o, mas como vemos em diversos posts, acabamos por achar que eles existem no framework.<\/p>\n\n\n\n <\/p>\n\n\n\n Antes da aplica\u00e7\u00e3o ser iniciada, no m\u00e9todo main, voc\u00ea pode usar o m\u00e9todo setAdditionalProfiles<\/em> da classe SpringApplication<\/em>. Importante voc\u00ea saber que ap\u00f3s a aplica\u00e7\u00e3o ter sido iniciada n\u00e3o \u00e9 mais poss\u00edvel trocar o perfil (at\u00e9 onde sei). Mais detalhes sobre os perfis do Spring Boot neste link<\/a>.<\/p>\n\n\n\n Calma, \u00e9 o \u00faltimo andar MESMO agora (por enquanto, pois n\u00e3o vou falar aqui do Spring Cloud). O Spring Boot adiciona mais uma abstra\u00e7\u00e3o importante referente a configura\u00e7\u00f5es: as auto configura\u00e7\u00f5es.<\/strong><\/p>\n\n\n\n Muita gente ignora este aspecto do “Boot”: o framework \u00e9 composto por diversos m\u00f3dulos que voc\u00ea pode adicionar ao seu projeto, identificados no Maven\/Gradle com o nome “spring-boot-starter-*”, e cada um destes m\u00f3dulos cont\u00e9m, al\u00e9m das suas pr\u00f3prias funcionalidades, suas pr\u00f3prias configura\u00e7\u00f5es (auto configura\u00e7\u00f5es), ativadas no momento em que a aplica\u00e7\u00e3o \u00e9 iniciada.<\/p>\n\n\n\n \u00c9 fundamental que voc\u00ea saiba disto<\/strong> por que temos aqui aplicado o conceito de conven\u00e7\u00f5es sobre configura\u00e7\u00e3o. O autor do m\u00f3dulo define qual ser\u00e1 o seu comportamento padr\u00e3o e cabe a voc\u00ea customizar o que \u00e9 necess\u00e1rio para o seu projeto.<\/strong> Mas a\u00ed entra a seguinte quest\u00e3o: como saber quais s\u00e3o estas configura\u00e7\u00f5es? Simples: voc\u00ea executa sua aplica\u00e7\u00e3o com o par\u00e2metro –debug e todas ser\u00e3o impressas no console. Exemplo:<\/p>\n\n\n\n E se eu estiver usando Maven ou Gradle no meu ambiente de desenvolvimento? D\u00e1 pra passar o par\u00e2metro tamb\u00e9m.<\/p>\n\n\n\n Sendo assim se voc\u00ea usa, por exemplo, o m\u00f3dulo JPA do Spring Boot: spring-boot-starter-jpa<\/em>, automaticamente \u00e9 configurado um datasource para voc\u00ea. E estas configura\u00e7\u00f5es variam de m\u00f3dulo para m\u00f3dulo, mas n\u00e3o fique triste. Mas como estas configura\u00e7\u00f5es s\u00e3o carregadas e onde est\u00e3o?<\/p>\n\n\n\n No momento em que a aplica\u00e7\u00e3o \u00e9 iniciada o Spring varre todos os arquivos JAR presentes no seu classpath que perten\u00e7am a estes m\u00f3dulos. E em cada um destes busca por um arquivo chamado spring.factories<\/em>, presente no diret\u00f3rio META-INF<\/em> do JAR. Neste arquivo est\u00e3o listadas as classes de configura\u00e7\u00e3o (@Configuration) que s\u00e3o as respons\u00e1veis por configurar aquele m\u00f3dulo.<\/p>\n\n\n\n Dica<\/strong>: leia este t\u00f3pico<\/a> da documenta\u00e7\u00e3o oficial do Spring Boot para entender como estes m\u00f3dulos s\u00e3o escritos.<\/p>\n\n\n\n <\/p>\n\n\n\n Agora que estamos no “\u00faltimo andar” \u00e9 muito importante que voc\u00ea tenha em mente o objetivo de que configura\u00e7\u00f5es devem ser externas ao seu c\u00f3digo fonte<\/strong>. Desde o seu lan\u00e7amento uma das principais features do Spring Boot foi o fato de ter “configura\u00e7\u00f5es externaliz\u00e1veis”<\/a>. A ideia \u00e9 simples: h\u00e1 um \u00fanico pacote da sua aplica\u00e7\u00e3o que ser\u00e1 implantado em diversos ambientes, cada qual com o seu pr\u00f3prio conjunto de configura\u00e7\u00f5es.<\/p>\n\n\n\n Um dos objetivos do Spring Boot \u00e9 que voc\u00ea tenha um conjunto de configura\u00e7\u00f5es padr\u00e3o para executar a sua aplica\u00e7\u00e3o, mas que possam ser alteradas de acordo com o ambiente no qual o projeto \u00e9 executado. Sendo assim voc\u00ea teria, por exemplo, configura\u00e7\u00f5es \u00fanicas para acesso a banco de dados no ambiente de produ\u00e7\u00e3o, teste, homologa\u00e7\u00e3o, desenvolvimento, etc.<\/p>\n\n\n\n Na documenta\u00e7\u00e3o oficial do Spring Boot voc\u00ea encontra este link<\/a> que descreve as 14 fontes usadas pelo Spring Boot na busca por configura\u00e7\u00f5es (properties). A ideia \u00e9 fornecer ao desenvolvedor (ou equipe de opera\u00e7\u00e3o) um mecanismo que permita sobrescrever de forma f\u00e1cil praticamente qualquer configura\u00e7\u00e3o usada pela sua aplica\u00e7\u00e3o.<\/p>\n\n\n\n Voc\u00ea pode ver a lista das 14 fontes no link que mencionei acima, mas vou copi\u00e1-la para c\u00e1 pois a usaremos para entender o funcionamento:<\/p>\n\n\n\n Muita confus\u00e3o<\/strong> surge a partir desta ordem de carregamento, ent\u00e3o vamos a um exemplo. Imagine que temos o seguinte arquivo “application.properties” (falaremos mais sobre este arquivo e suas variantes adiante, contenha sua ansiedade) no seu projeto:<\/p>\n\n\n\n Se sua aplica\u00e7\u00e3o for compilada e executada sem quaisquer informa\u00e7\u00e3o adicional (java -jar Aplicacao.jar) os valores definidos neste arquivo ser\u00e3o mantidos (item 3). Sempre o Spring Boot verifica todos os elementos da lista ao executar a aplica\u00e7\u00e3o, sendo assim vamos continuar no exemplo para que a coisa fique mais simples, pois h\u00e1 uma pegadinha envolvendo algo sobre o qual falei no in\u00edcio deste post.<\/p>\n\n\n\n Se houver uma vari\u00e1vel de ambiente chamada “nome” com o valor “Nanna”, teremos aqui o valor “Nanna” aplicado na configura\u00e7\u00e3o (item 5, posterior ao 3).<\/p>\n\n\n\n Se for passada a propriedade de sistema nome via par\u00e2metro (“-Dnome=Juca”) para a aplica\u00e7\u00e3o, o valor ser\u00e1 “Juca” (item 6, posterior ao 5 e 3). Sendo assim voc\u00ea pode sobrescrever vari\u00e1veis de ambiente na execu\u00e7\u00e3o do seu projeto tamb\u00e9m.<\/p>\n\n\n\n At\u00e9 chegarmos ao item 11: “par\u00e2metros de linha de comando”. Aqui o Spring Boot reconhece o valor de vari\u00e1veis da seguinte forma: “–nome=Jucolino”. Sendo assim, se defini a vari\u00e1vel nome no arquivo (item 3), tamb\u00e9m uma vari\u00e1vel de ambiente com mesmo nome (item 5), mesmo assim ainda fui l\u00e1 e coloquei uma propriedade de sistema (item 6), se eu incluir um “–nome=JucolinoBruto” por linha de comando, prevalece o item 11 (em teoria).<\/p>\n\n\n\n Via de regra: as fontes de configura\u00e7\u00e3o que tenham ordem maior s\u00e3o as que ser\u00e3o carregadas pelo seu projeto durante a inicializa\u00e7\u00e3o.<\/p>\n\n\n\n Muito cuidado com o item 3 da lista acima: arquivos de configura\u00e7\u00e3o. Aqui reside boa parte dos problemas que vejo as pessoas enfrentarem em seu dia a dia. Isto por que estes arquivos se dividem em duas categorias:<\/p>\n\n\n\n O Spring Boot, tal como descrito em sua documenta\u00e7\u00e3o<\/a>, carrega estes arquivos na seguinte ordem:<\/p>\n\n\n\n Sendo assim, imagine que eu tenha o arquivo application.properties embarcado em meu projeto com o seguinte conte\u00fado:<\/p>\n\n\n\n Esta propriedade define a porta do servi\u00e7o que identificar\u00e1 minha aplica\u00e7\u00e3o. Se for ativado o perfil “dev” no projeto, e existir internamente um arquivo chamado “application-dev.properties”, e neste o valor da propriedade “server.port” for “9090”, o valor usado pela aplica\u00e7\u00e3o ser\u00e1 o “9090”.<\/p>\n\n\n\n Mas e se eu ativar mais de um perfil na minha aplica\u00e7\u00e3o, digamos, “dev,qa”. Os arquivos nos quais a chave ser\u00e1 buscada no classpath ser\u00e1:<\/p>\n\n\n\n Se no mesmo exemplo a propriedade “server.port” estiver definida tamb\u00e9m no arquivo “application-qa.properties” com valor “1234”, “1234” ser\u00e1 o valor da propriedade no final.<\/p>\n\n\n\n<\/figure>\n\n\n\nVari\u00e1veis de ambiente<\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n\nexport nome=Kico<\/pre>\n\n\n\n
System.out.println(System.getenv(\"nome\");<\/pre>\n\n\n\n
Kico<\/pre>\n\n\n\n
Propriedades do sistema<\/h3>\n\n\n\n
public class Programa {\n public static void main(String args[]) {\n System.out.println(System.getProperty(\"nome\"));\n }\n}<\/code><\/pre>\n\n\n\njava -Dnome=Kico<\/strong> Programa<\/pre>\n\n\n\n
Segundo andar: Spring<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\nPropriedades (Properties)<\/h3>\n\n\n\n
Environment (Ambiente)<\/h3>\n\n\n\n
Property Source<\/h3>\n\n\n\n
@PropertySource(\"file:\/\/\/home\/kicolobo\/configsfelizes.properties\")<\/strong>\npublic class AplicacaoSpringBoot {\n ...\n}<\/pre>\n\n\n\nProfiles (Perfis) – muita aten\u00e7\u00e3o aqui!<\/strong><\/h3>\n\n\n\n
<\/figure><\/div>\n\n\n\n@Configuration<\/strong>\npublic class ConfiguracaoDAO {\n @Bean @Profile(\"Relacional\")<\/strong>\n public DAOUsuario getDAORelacional() {\n return new DAOUsuarioMySQL();\n }\n\n @Bean @Profile(\"NoSQL\")<\/strong>\n public DAOUsuario getDAONaoRelacional() {\n return new DAOUsuarioMongoDB()\n }\n}<\/pre>\n\n\n\nSelecionando os profiles<\/h4>\n\n\n\n
Por system property<\/h5>\n\n\n\n
java -Dspring.profiles.active=prod AplicacaoLinda.jar<\/pre>\n\n\n\n
java -Dspring.profiles.active=prod,relacional AplicacaoSuperPoderosa.jar<\/pre>\n\n\n\n
<\/figure><\/div>\n\n\n\nProgramaticamente <\/h5>\n\n\n\n
Terceiro andar: Spring Boot e suas auto configura\u00e7\u00f5es<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n\njava --debug -jar AplicacaoLinda.jar<\/pre>\n\n\n\n
Carregando configura\u00e7\u00f5es<\/h1>\n\n\n\n
<\/figure>\n\n\n\nOrdem de carregamento<\/h2>\n\n\n\n
nome=Kico
sobrenome=Lobo<\/pre>\n\n\n\nArquivos de configura\u00e7\u00e3o<\/h2>\n\n\n\n
server.port=8080<\/pre>\n\n\n\n
![\"Foto](\"https:\/\/images.pexels.com\/photos\/417070\/pexels-photo-417070.jpeg?auto=compress&cs=tinysrgb&h=750&w=1260\")
<\/figure>\n\n\n\n