In reference to below issue https://github.com/watson-developer-cloud/spring-boot-starter/issues/7 . we have to change prefix to kebab-case in java files. But what if one of the dependency jar files references to a prefix in a format like #ConfigurationProperties(prefix="MY_CONFIG"). Is there a solution to this problem ?
Is there a solution to this problem ?
I assume you're using Spring Boot 2.x. It tightened up some of the rules around relaxed binding such that the use of the canonical form (kebab-case) is now required in the prefix on #ConfigurationProperties. (Camel case, snake case, and kebab case are all still supported in application.properties files).
The only solution is to update all #ConfigurationProperties annotations to meet Spring Boot 2.0's requirements. In this case that'll require a change to your dependency jar. Note that a #ConfigurationProperties annotation with a prefix in kebab-case will work with both Spring Boot 1.x and 2.x so you should not encounter any backwards compatibility problems with the change.
It will work and you can still use camelCase or UPPER_CASE due to Spring's relaxed binding feature.
Related
Apache Camel provides two ways to integrate with Spring Boot:
camel-spring-boot
camel-spring-boot-starter
When I look at the starter then I see that it only includes camel-spring-boot and spring-boot-starter. What is the difference then and what are the advantages of using starter?
At the moment of writing this answer, camel-spring-boot is only supported from Camel 2.15 and camel-spring-boot-starter only from Camel 2.17, which is important considering the current version that your project is using.
Then the major difference between these two dependencies, lies in the "opinionated" auto-configuration provided by the starter.
camel-spring-boot, should be used if you want just to include a jar to make your camel routes auto-discovered by spring boot, this also gives you the freedom to update this dependency regardless of your spring-boot version.
camel-spring-boot-starter, (recommended way to go) should be used if you want a collection of dependencies (including camel-spring-boot) that provides the best developer/user experience, due to the fact of customizable properties, additional libraries, and default configuration for the camel library. Check the reference documentation for the starter: https://camel.apache.org/components/latest/spring-boot.html#_spring_boot_auto_configuration
Summary
Use camel-spring-boot, if you want a vanilla jar to use camel with spring boot
Use camel-spring-boot-starter, if you want an automatic-configured component to start to develop with.
You should always use the camel-xxx-starter dependencies, as these are the Camel components that is support with Spring Boot. Also as mentioned they provide auto configuration and some of them additional capabilities.
If there is no camel-xxx-starter component then its because its not supported on Spring Boot with Camel.
See more at: https://github.com/apache/camel/tree/master/platforms/spring-boot/components-starter#camel-component-starters
The Spring Boot documentation says how to name a Spring Boot starter for something with a simple name such as acme: acme-spring-boot-starter
However, the autoconfigured "thing" has not always such a simple name. How about a name with multiple parts?
For example CXF "splits" these parts around the base name to express a project-component hierarchy:
cxf-spring-boot-starter-jaxws
cxf-spring-boot-starter-jaxrs
I found other variants with these naming patterns
foo-bar-spring-boot-starter
spring-boot-starter-foo-bar (probably not ok because of possible conflict with starter of Spring Boot project)
Is there a naming convention or recommendation?
https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-custom-starter
Suffix should be -spring-boot-starter so in your case I'd say:
cxf-jaxws-spring-boot-starter
cxf-jaxrs-spring-boot-starter
We have some xml that uses capitol letters for all fields. Spring boot automatically uses jackson which does not work well with this. I have the xml "jaxb"d into java objects that tell it to use the capitol letters. However spring always seems to use Jackson.
Anyway to force it to use Jaxb?
You can find here a list of commonly used in spring-boot properties for your application.properties file. You probably need:
spring.jackson.property-naming-strategy=UPPER_CAMEL_CASE
Here are the available naming strategies for Jackson.
If you insist on Jaxb I believe it will be used by spring boot unless you include jackson-dataformat-xml in your classpath (may have to exclude it).
Essentially what I'm trying to do is to add this property change to hibernate so I can enable instantiation of composite/embeddable objects when all of its attribute values are null:
hibernate.create_empty_composites.enabled
I am aware that the usual way to edit Hibernate is in the application.properties file like so:
################################################################################
# JPA MANAGEMENT #
################################################################################
spring.jpa.hibernate.naming.physical-strategy=org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
spring.jpa.properties.hibernate.enable_lazy_load_no_trans=true...
...
spring.jpa.properties.hibernate.create_empty_composites.enabled=true
But the spring.jpa.properties.hibernate.create_empty_composites.enabled=true isn't working. I'm not sure if Spring just doesn't recognize certain properties or if it's just the wrong place to put it.
What I'd like to know is if there is another way to edit the Hibernate properties directly or if there is another fix.
Analysis
The base assumption. More likely you are using Spring Boot 1.5.*.
Spring Boot 1.5.* uses Hibernate 5.0.*. GitHub proof.
Hibernate supports the hibernate.create_empty_composites.enabled setting since the 5.1 version.
GitHub proof.
JIRA proof (?): [HHH-7610] Option for injecting empty (non-null) embedded when all columns are NULL - Hibernate JIRA.
Release notes proof: ORM 5.1 feature release.
Solution
Please consider upgrading the Hibernate dependency in your pom.xml to a more recent version (5.1 and higher).
After that, it should work just fine:
In addition all properties in spring.jpa.properties.* are passed through as normal JPA properties (with the prefix stripped) when the local EntityManagerFactory is created.
— Spring Boot 1.5.* reference, 77. Data Access, 77.5 Configure JPA properties.
I am trying to use apache commons configuration replacing a PropertiesFactoryBean in a spring application.
It seems to me but commons configuration framework is not compatible with PropertyPlaceHolderConfigurer nor with #Value annotations.
If you suggest me a solution please note that I have spring configured only with xml.
Thanks,
Mario
You are correct. commons-config is ancient, and wouldn't know an #nnotation from a garden-snail. #Value implies a ton of expensive mechanism involving reflection and inspection of annotation -- if you still need #Value, you might need to reconsider getting rid of Spring.
For future reference: the previous answer is no longer correct. Commons Configuration is able to interact with the PropertyPlaceholderConfigurer, see
http://commons.apache.org/proper/commons-configuration/userguide/howto_utilities.html#Use_Configuration_in_Spring for details.