I have been looking for an explanation of how Spring Framework will look for #AutoWired properties. I have noticed that when using the hikariCP library that setting either of the properties below will result in a correct max pool size.
spring.datasource.hikari.maximumPoolSize=3
or
spring.datasource.hikari.maximum-pool-size=3
Does Spring use both camel case and hyphen separated to lookup autowired properties? Where might I find an explanation in the spring docs?
That isn't a feature of the core Spring Framework but rather a feature of Spring Boot.
Spring Boot has a feature called relaxed binding which is used for properties mapped to a class annotated/used with #ConfigurationProperties. Each property that is being bound can be used with camel-case, dashes or even uppercase with dashes (generally used for environment variables!).
So all of these will work in the same way (the latter is often used to pass it as an environment or system variable).
spring.datasource.hikari.maximumPoolSize=3
spring.datasource.hikari.maximum-pool-size=3
SPRING_DATASOURCE_HIKARI_MAXIMUMPOOLSIZE=3
There are valid and invalid properties, but Spring's #ConfigurationProperties, which used mostly for loading configurations, works with both forms of properties.
The issue can be if any framework, library, etc. use property separately, without #ConfigurationProperties. In this case, you will have runtime exception (or null value).
Most default, base, popular properties are here: https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html
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.
New to Spring Boot here, long-time Spring Framework user though.
I'm looking for a way to split my externalised configuration into multiple .properties files, for better readability and manageability.
I already saw this SO answer: having the ability to specify a list of configuration file names in spring.config.name (which, by the way, doesn't seem to be mentioned in Boot reference documentation, correct me if I'm wrong) would solve my problem perfectly, however that configuration property can be specified only via system properties or environment variables. If I try to specify it inside my application.properties file, it gets ignored. The same happens for spring.config.additional-location. I understand this happens because, when application.properties is read, it's too late to tell Spring Boot to search for different externalised configuration file names. However this is not a proper solution, because the way I split my configuration should be an "implementation detail" that the consumer of my application shouldn't be aware of, so I don't expect the consumer to specify an external parameter otherwise my application breaks out-of-the-box.
I think that a way to do this should be provided. Perhaps some import mechanism for .properties files or the ability to specify spring.config.name even in application.properties (some known and reasonable limitations would be acceptable).
The best I could find out is to use #PropertySource, but this is not profile aware: unless you use some ugly nested class hack, or you put spring.profiles.active variable in the resource name (which will break if multiple profiles have been activated), you won't get the benefit you have for application.properties profile-specific files.
I was not able to find an "official way" to do this, apart from some statements from Spring Boot devs that say that they're rather promoting the use of a single (possibly giant...) externalised configuration file. It seems like this position is not so popular, judging from the post reactions on GitHub, and IMHO it really seems to be a basic feature missing. I have been working with multiple properties files in Spring Framework (using XML configuration) for years and I never felt that having an only huge file would have been better.
If I understand it right, in Boot 1.x this was in some way possible using the location attribute of #ConfigurationProperties, which is however missing in Boot 2.x.
Any suggestion?
Have you tried with Spring Profile?
What you can do is create application-file1.properties/yml, application-file2.properties/yml and put it in config location and then add spring.profile.active=<your env profiles>,file1,file2.
It will load the files.
This profile entry can be in bootstrap.yml, or JVM args to application, in Manifest-<env>.yml in case of Pivotal Cloud Foundry. Not sure on AWS and other cloud provider.
Hope this will help.
I have a property file like myProperties.properties. I want to read one property like MAX_YEARS using spring annotation #value as like below in UIMA JCasAnnotator_ImplBase extending class.
private #Value("${REQUIRED_COLUMNS}") String requiredColumns;
Or any alternatives for reading properties from property file in UIMA framework.
Thanks in advance.
Narasimha.
UIMA does not support value injection via Java annotations (from Spring or any other DI frameworks) at this time. It does support External Configuration Parameter Overrides, though.
uimaFIT offers annotations like #ConfigurationParameter to inject UIMA parameters into fields. These parameter values can come from descriptors automatically generated by uimaFIT using reflection, or they can come from pre-built XML descriptors.
When using pre-built XML descriptors, it should be possible to employ the External Configuration Parameter Overrides mechanism in conjunction with uimaFIT - but I am not sure if this has already been tried by anybody.
It may even be possible to employ the External Configuration Parameter Overrides mechanism with the descriptors internally generated by uimaFIT.
Disclosure: I am a developer on the UIMA project, focussing on uimaFIT.
I'm just learning Spring Security, and a lot of Spring's documentation appears to use Java-based bean configuration (as opposed to XML.) Overall, this seems to be the way a lot of their projects are going. However, portions of their documentation tend to start with Java configuration and then switch to XML config later on. I found a blurb in one document (http://docs.spring.io/spring-security/site/docs/3.2.0.RELEASE/reference/htmlsingle/) stating the following:
Spring Security’s Java Configuration does not expose every property of every object that it configures. This simplifies the configuration for a majority of users. . . . While there are good reasons to not directly expose every property, users may still need more advanced configuration options. To address this Spring Security introduces the concept of an ObjectPostProcessor which can used to modify or replace many of the Object instances created by the Java Configuration.
Can everything that can be done in XML configuration be done with Java config? Is there a definite direction that the Spring community is taking overall in terms of configuration style?
You can choose either java based or xml based configuration.Stick to one, don't mix both.But don't forget to use the annotation based configuration.You just need to annotate spring managed components with #component,#service etc.You don't need to have that bean defenition in xml or java class.
<context:annotation-config/>
<context:component-scan base-package="com.package"/>
or
#Configuration
#ComponentScan({"com.foo.bar", "org.foo.bar"})
http://docs.spring.io/spring-security/site/docs/3.2.0.RC2/reference/htmlsingle/#jc
You can use Java or XML based. But there is a thing
Usage of xml based configuration is decreasing in newer versions of Spring.
Like #EnableAutoConfiguration tag...
With this, web applications doesnt need any XML conf even web.xml
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.