We have customized Spring cloud config as a centralized solution for enterprise as a result of which there are around 700 repos onboarded to our config server. It adds up to approx 7000 spring configuration properties and it will keep increasing. This used to work pretty fast in spring boot 1.5 but post-spring boot 2.0 Its taking a lot of time to map the configuration properties.
I am trying to upgrade it to Spring boot 2.1.8 along with spring cloud config 2.1.4 but application startup time and context refresh time has drastically increased when compared to spring boot 1.5.x.
Is there a way we can switch off relax binding or other mapping features and use it similar to spring boot 1.5?
I don't have an experience of managing such a big amount of properties, however I have some ideas that can be useful and point to the solution:
Why do you think its property resolution/relaxed binding rules? Maybe there are some more beans that get loaded and some of them are slow, all the can "contribute" to the slow startup time.
For modern machines 7000 properties is not such a big amount. So the chances are that even there was some performance degradation between spring boot 1.x and 2.x (in which I hardly believe) - it still won't be a "considerable" amount of time.
Since you've mentioned spring cloud config - it has a rest API that can by itself be checked for performance. If you have an actuator on the cloud config server, there is an endpoint that returns 50 last requests along with their execution times. So please check the execution times and compare between spring boot 1.5.x and 2.0.x
Last but not least - try to profile the application and see which beans are the real time consumers.
Related
StreamsBuilderFactoryBeanCustomizer and StreamsBuilderFactoryBeanConfigurer are both used to customize the StreamsBuilderFactoryBean. These 2 interfaces seem redundant and one of the two should certainly be deprecated before being abandoned.
This works well when using the default Spring configuration but it can become a pain when custom StreamsBuilderFactoryBean(s) need(s) to be created.
Any specific reason/constraint explaining the need of these 2 interfaces?
Any feedback is more than welcome.
StreamsBuilderFactoryBeanConfigurer is provided by Spring for Apache Kafka.
The customizer is a Spring Boot class.
Not all users use Spring Boot although, admittedly, most do. Furthermore, the ...Configurer extends Ordered so you can control the order in which multiple configurers are invoked.
It used to be worse - they were both called ...Customizer until Spring for Apache Kafka version 2.6.7.
https://github.com/spring-projects/spring-kafka/issues/1736
They were added to their respective projects:
Spring for Apache Kafka: Feb 28 2019 https://github.com/spring-projects/spring-kafka/commit/9e86163647217dd9cefb5e35c974eb476cefc150
Spring Boot: Jul 1, 2020: https://github.com/spring-projects/spring-boot/commit/54e0a61b425d00ceb220b82dc8abbad121245c10
So, it appears that Boot added its own customizer unnecessarily.
You could try opening an issue against Boot to see if they are prepared to deprecate theirs (since ours predates it), but we can't remove it from Spring for Apache Kafka for reasons stated.
I have a Spring Boot app with caching enabled using the #EnableCaching in the main class and #Cacheable for certain methods. This was earlier working well.
Now I have also configured GemFire cache to store other data.
The older code with the #Cacheable annotation is now trying to fetch this data in the GemFire cache. Is there a way to define when to use which cache?
I'm new to this and would appreciate any inputs on the best practice to be followed in such case and what can be done to overcome this.
Have a look at this: https://docs.spring.io/spring-boot-data-geode-build/current/reference/html5/#geode-caching-provider, and specifically this: https://docs.spring.io/spring-boot-data-geode-build/current/reference/html5/#geode-caching-provider-disable.
If you are not using Spring Boot for Apache Geode (SBDG; see project home as well as the docs) (which also applies to VMware Tanzu GemFire as well, given GemFire is based on OSS, Apache Geode), then you most definitely should consider it.
If you need to control which cache is used for which, e.g. service method, then you should read more about custom cache resolution as opposed to the default cache resolution strategy.
Last, SBDG honors Spring Boot's Caching configuration, after SBDG is essentially Spring Boot specifically designed and developed for Apache Geode (and GemFire).
My team currently has an old JSF 1.1 / Spring2 / Weblogic Monolith Application. As we start towards modernizing our application they want us to take our current architecture, as is, and basically shoe horn it into Spring Boot.
We aren't talking about breaking it down into micro-services at this point, but basically a lift from our current setup, taking Weblogic out of the picture, and running it in Spring Boot with Hikari Data Sources.
Can this be easily done? I haven't found a way to do it without extensive code changes and I don't mind suggesting a "Lets break it down into a micro-services in the next Product Increment" approach.
Outside of re-architecting our application (as we plan in the future) or doing quite a lot of code change, are there any other options?
If you do not use JavaEE for Weblogic, you can migrate your application to the Spring Boot easy enough. The main thing is the correct import of configuration, components, resources and properties. See: example.
If you used in your legacy project JPA or even JDBC to rewrite backend to Spring Data is not very difficult.
From my point of view the main difficulty is the JSF version you are using. I would refuse it, because: 1) it is not fully compatible with Spring boot and 2) it is already out of date today. It takes a lot of effort to put it into the Spring Boot and still it will not work completely. If there is no time and resources to change this view technology to another, you will have to finish it to Spring Boot.
I don't see other real alternatives
I've found quite a huge pile of topics that give the answer for the opposite question: "Why choose Spring Boot over Spring?", but I guess somebody can give an example that will justify Spring selection over Spring Boot.
You can found several cons on Spring boot over Spring, mainly missing learning steps in Spring and support and if using monolithic application
If you are new to Spring and want to learn how the dependency injection, AOP programming, and proxies work, starting with Spring Boot is not a good choice. Spring Boot hides the most of these details from you.
If you are not familiarized with other projects of the Spring ecosystem (Spring Integration, Spring AMQP, Spring Security, etc), using them from Spring Boot will make you miss a lot of concepts
In a large and monolithic based applications, I wouldn’t encourage you to use Spring Boot
Also can increase deployment size
Spring boot may unnecessarily increase the deployment binary size with unused dependencies.
I have just started learning spring boot . In its official page I found out this term and I did not understand that what actually it meant in Spring boot context.
Spring Boot just decides on a set of default configured beans which you can override if you want.
For example if you include the spring boot starter pom for jpa, you'll get autoconfigured for you an in memory database, a hibernate entity manager, and a simple datasource. This is an example of an opinionated (Spring's opinion that it's a good starting point) default configuration that you can override.
See https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-replacing-auto-configuration
Spring Boot, is Spring on steroids if you will. It's a great way to get started very quickly with almost the entire Spring stack. I'll try to summarize as what "Opinionated Defaults Configuration" would mean in practice from a programmer's perspective below:
Helps you to setup a fully working application(web app or otherwise) very quickly by providing you intelligent default configurations that you are most likely to be satisfied to start with.
It does so by something called "AutoConfiguration", where capabilities from the Spring ecosystem of products are "auto-magically" enabled in your application by adding certain dependencies to your classpath; adding such dependencies via maven or gradle is super easy.
Most auto-configuration respects your own configuration, and backs off silently if you have provided your own configuration via your own beans.
You would benefit most if you take the java config approach of configuring your Spring application.
Super silky integration of new capabilities in your application by developing your own auto-configuration components (via annotations!).
Tons of auto-configaration components available ranging from Databases(h2, derby etc.), servlet containers(tomact, jetty etc.) to email and websockets are available. It is easy to develop your own. The important thing is that others can use those technology enablements in their own components. Please feel free to contribute.
Helps write very clean code with all the heavy lifting taken care of you, so that you can focus more on your business logic.
Hope you have fun with Spring Boot; its absolutely among the very best of frameworks to have hit the market in the last decade or so.
It follows opinionated default configuration so it reduces the developer efforts. Spring boot always uses sensible opinions, mostly based on the class path contents. So it overrides the default configuration.