Remove locations attributes from #ConfigurationProperties
What are the alternatives?
I've been using it like this before.
#ConfigurationProperties(locations = "a.yml")
Same problem here: we have hundreds of configuration keys on several yaml files, each of them conveniently mapped to a pojo that we inject into our business logic beans.
The best thing I could do to upgrade to Spring Boot 1.5 and at the same time keep our production application running without much refactoring is described here: http://fabiomaffioletti.me/blog/2016/12/20/spring-configuration-properties-handle-deprecated-locations/
Or, if that does not work for you, you can try this way which is simpler even if requires more refactoring (remove the #ConfigurationProperties annotation): http://fabiomaffioletti.me/blog/2017/02/09/spring-configuration-properties-locations-deprecation-another-approach/
Related
I learning Spring boot and found that in some examples use the same properties with the prefix spring.jpa.properties while other do it without prefix.
For instance:
The article explains second level cahche https://www.baeldung.com/hibernate-second-level-cache and autor shows example of needed properties ( example on autor's gitHub):
hibernate.cache.use_second_level_cache=true
hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
But it did not work for me, and I spent few hours loking for the reason, but then i noticed, someone use prefix spring.jpa.properties. to get it working (Exact moment from video lesson):
spring.jpa.properties.hibernate.cache.use_second_level_cache=true
spring.jpa.properties.hibernate.cache.region.factory_class=org.hibernate.cache.ehcache.EhCacheRegionFactory
Which perfectly worked for me.
So my questions are:
why are they working in different way?
how to understand which properties in which cases requires this prefix?
is it probably something related to my project settings OR Spring Boot version?
any other suggestions are appreciated :)
Thank you in advance!
There are a couple of things in play here. First the tutorial you use is using plain Spring not Spring Boot. Which means a manually configured EntityManagerFactory on which you directly can set the provider specific properties. Like hibernate.cache.use_second_level_cache.
As you decided to use Spring Boot you don't have a manually configured EntityManagerFactory (although you could!). Which means you are using an autoconfigured EntityManagerFactory. Properties for this reside in the spring.jpa namespace for properties.
As it isn't feasible to specify properties for each and every extension for Hibernate (or other JPA providers) only some commonly used ones are exposed like spring.jpa.generate-ddl and a few provider specific ones in the spring.jpa.hibernate namespace. However to set all the other properties in an autoconfigured way there needed to be something else. Hence the spring.jpa.properties prefix. Anything specified in there will be passed on as is (without the said prefix ofcourse) to the EntityManagerFactory for configuration.
Over the course of writing Spring Boot apps, our team adds in a lot of #Value annotations to help make things configurable. At some point we start to lose track of exactly what we added and what can be configured. We get a lot of questions from the QA and DevOps teams about what exactly can be configured and what can't.
Currently we just do a grep through the code base and apply some crude regular expressions to try and parse out the meaningful pieces. But this doesn't catch 100% of cases and inevitably we end up digging through the code to find out what fields can be configured.
I know we could use JavaDoc to somewhat achieve our goal, but the documentation would be buried with other JavaDoc (methods, fields, classes, etc) and it's still reliant on developers to remember to add the JavaDoc to each field.
Has anyone found a more automated way to document their #Value fields? I'm thinking something like Swagger, but specifically for Spring and the various ways it can externalize configuration.
Javadoc is indeed a way to document for developers, not the QA or the operators.
Your question is really interesting but answering to that canonically is hard because #Value are implementation details of components. Swagger that you quote documents REST contracts, that is an important difference.
Here some ideas :
Writing a BDD test for them that could be used too as documentation makes really no sense functionally but technically it makes.
Indeed, you could write a BDD integration test (with Cucumber or any other library) where you document and test the presence of each expected property.
Not a perfect solution, but you could at least retrieve exposed properties and a little more with these Spring Boot actuators :
configprops : Displays a collated list of all #ConfigurationProperties.
env : Exposes properties from Spring’s ConfigurableEnvironment.
Whenever you can, favor #ConfigurationProperties injection to group properties that work together rather than #Value. Isolating them in #ConfigurationProperties classes and adding javadoc for them is not bad at all to document their presence and usage.
as suggested by caco3 you can also generate your own metadata by using the Annotation Processor :
You can easily generate your own configuration metadata file from
items annotated with #ConfigurationProperties...
The processor picks up both classes and methods that are annotated
with #ConfigurationProperties. The Javadoc for field values within
configuration classes is used to populate the description attribute.
It joins with the previous point : favoring #ConfigurationProperties whenever it is possible.
what's the easiest way to get the spring boot goodness but not try to autoconfigure all the things? For instance, to only run flyway with our already configured properties (some loaded via Consul + Spring Cloud), I was hoping I could do something like:
#Configuration
#Import({DataSourceAutoConfiguration.class, FlywayAutoConfiguration.class})
public class FlywaySetup {}
and have the main method just call SpringApplication.run(FlywaySetup.class)
The problem with this is it picks up all the Component Scan / crazy long list of other dependencies. Any way to specifically configure the dependencies (but still get the nicities of the framework)
If you run this app, it shouldn't use component scan at all. There's nothing that triggers component scan in spring boot besides #ComponentScan (that's available on #SpringBootApplication).
It would help if you could provide more accurate details rather than "crazy long list of other dependencies.". Running that FlywaySetup should only load those two configuration classes (important: these are not handled as auto-configuration anymore). If you have component scan, there's something else you're not showing.
You can exclude auto-configurations you don't need.
You may want to take a look at this SO answer to explore mechanism how to do that.
I started learning spring today and i have a question regarding what happens to the annotations when java files with annotations is compiled ?.
The reason i am asking this is because of the fundamental difference i see when we choose to use the xml approach vs the annotations approach , and what i think is the philosophy of spring. The way i understand is spring says that all your java classes can be simple pojo's and all the spring related config should be kept independent (Like xml file.)
In case of developing spring application using xml *.java files have no idea about spring container and are compiled in to .class without any spring related dependencies.
But now when we annotate the .java file and the file is compiled the compiled file now has all spring related dependencies hard baked in to it and no longer are your classes simple pojo's.
Is this correct ? I am not sure if i am missing some thing here.
Annotations can be considered as metadata of a class or its element (method, field, local variable...). When you put annotation, you don't implement any behaviour. You just give additional info on an element.
That way, Spring, which is in charge of instanciating its bean can collect the info with reflection (see also this site) and process it.
To conclude, your Spring beans still remain POJO and there is no difference with the XML way (...from that point of view) since Spring gets from annotations the information it would have got from XML .
I think you are right and your question is justifiable, that's the way how I think about it too.
Not only compiled code but also dependency on spring jars bother me. Once you use this annotations your resulting jar depends on spring library.
It's reasonable to store beans in model according to DDD but spring is some kind of infrastructure layer so I didn't like the dependency.
Even if you would use XML, it's useful for few placed to use attributes. E.g. #Required attribute which is useful to verify that linked bean was injected. So, I've decide to use constructor dependency injection to omit this attribute, see my article. I completely leave out the dependency on spring in the code.
You can probably find such mind hook for many annotation you want/force to use.
You can use annotations only for your configuration classes, without marking them actual bean classes. In such scenario if you not use spring you just not load configuration classes.
On Spring #Autowired usage question most of the people answer they prefer not using configuration files, if possible. It seems like a good answer at the first glance.
However, once you have quite a big application which uses Spring IoC and autowires all the stuff using annotations #Autowired, #Service, etc. you must hit this problem: you no longer are able to keep track of your bean dependencies.
How do you deal with that?
Using SpringSource Tool Suite one can create graphs of dependencies on the basis of configuration files.
Is there any tool out there which does the same with #Autowired stuff? (I understand graphs would have to be created on runtime).
Implement BeanFactoryAware and cast the factory that is passed into setBeanFactory() to a DefaultListableBeanFactory. Then use DefaultListableBeanFactory.getBeanDefinitionNames() and DefaultListableBeanFactory.getDependenciesForBean() to generate the dependency graph.