2. Context
Atualizado
Atualizado
Sempre que o Spring iniciar a aplicação, ele irá olhar para essa classe e levará em consideração as customizações e configurações que definirmos nessa classe de Configuração.
Ele irá buscar pelos Beans que ele irá gerenciar. Serve só para algo customizado mesmo, pois o Spring em sí já faz uma varredura automática ao ser iniciado.
@Configuration
@ComponentScan(basePackages = "com.api.parkingcontrol")
public class BeanConfig{}Criamos uma classe, por exemplo, chamada MyBean.
Dentro da BeanConfig, criaremos um método que irá retornar exatamente o Objeto que criamos.
@Bean
public myBean myBean() {
return new MyBean();
}Pro Spring saber detectar que esse MyBean será um Bean gerenciado, precisamos passar @Bean.
Para podermos visualizar o que está dentro da Classe MyBean, faremos uma injeção de dependência dentro da Classe ParkingSpotController, assim como fizemos com o @Value.
Usa o Autowired para fazer a importação do MyBean, e pode chamar o metodo com myBean.method(). Veja aqui
Ok, isso foi um Bean criado por nós. Mas eventualmente usaremos Beans advindos de bibliotecas terceirizadas, como fazer nestes casos?
Dentro do nosso pom, inserimos uma dependência modelmapper, utilizada para conversões. Veja aqui
Declaremos o Bean ModelMapper dentro da classe que iremos utilizar, mostrando que mesmo que esse Bean não tenha sido criado por nós, o Spring irá também gerenciá-lo.
(dentro da classe config)
@Bean
public ModelMapper modelMapper() {
return new ModelPapper();
}E dentro da controller, que é onde iremos iniciar, faremos a injeção. Veja aqui
Mas podemos fazer um "start preguiçoso". Ou seja, falar pro Spring criar esse Bean somente quando precisar.
Passamos a anotação @Lazy e será feito dessa maneira.
E como acionar esse Bean em um momento específico pro Spring criar?
Bom, mesmo de sempre. Faremos a injeção de dependência no controller com @Autowired importanto o Bean e assim o Spring carregará o método com @Lazy. Veja aqui
Caso esse LazyBean não esteja importado dentro de algum método, não será inicializado pois o Spring não encontrará nenhum ponto de injeção de dependência.
Se você não especificar qual dessas o Spring irá considerar nos pontos de injeção que vamos criando, ele entrará em conflito. Precisamos declarar qual ele irá utilizar. Tipo quando passamos o arquivo no @Qualifier.
Então esse @Qualifier não irá existir. Usaremos, portanto, o @Primary. Veja aqui
Utilizaremos o parâmetro singleton, conforme vimos na parte de Beans. Em suma, o @Scope define como o Spring irá lidar com as criações dos Beans (dependendo do parâmetro).
Cabe destacar que o Sring lê a application.properties por default.
Podemos criar no package Resources um "custom.properties". Contendo o que desejarmos. No controller, criaremos uma várivel do tipo de conteúdo que criamos no arquivo "properties". Se for uma String, criaremos uma variável tipo String usando Anottation @Value. Veja aqui
Mas isso não é o suficiente. O Spring precisa saber o arquivo pro Spring. Passamos a anotação @PropertySource("classpath:custom.properties") Veja aqui
Nessa situação, passaremos o @Profile dizendo qual será qual. Porém, essa forma não é a ideal, ao inciarmos a aplicação teremos um conflito. O Spring não consegue saber qual perfil está ativo.
Jeitos de realizar
Na nossa application.properties, colocaremos logo no começo: spring.profiles.active=dev ou =prod (o que tiver no @Profile).
Ao invés de usarmos a anotação dentro no método dentro da BeanConfig, criaremos uma classe para cada Profile. E assim sendo, declararemos o @Profile na classe em sí. Veja aqui Na .properties mantém o que a gente quer passar no profile.active. O que muda mesmo é onde declaramos o @Profile.