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.
Related
I'm working on application which uses Spring Core in version 4.3.14 and Spring Web in version 4.2.13. We don't use Spring MVC. Also, from Spring Web we use just very limited set of classes:
XmlWebApplicationContext (so classes from org.springframework.web.context)
RestTemplate (so classes from org.springframework.web.client, here i expect some problems)
some util classes which probably can be refactored to use something else
My question is:
We want to migrate to Spring 5.x. Is such a migration really possible? Or should i expect some severe problems with application startup (class incompatibilites etc). This source for example: https://github.com/spring-projects/spring-framework/wiki/What%27s-New-in-Spring-Framework-5.x#whats-new-in-version-50 says that Servlet 3.1 is required
From the other side, here https://spring.io/blog/2015/06/10/feedback-welcome-spring-5-system-requirements JUERGEN HOELLER wrote that migration to Spring 5 will be a soft one. So i assume that if Application uses only features from JEE6 + Servlet 3.0, then it can be that it will also work on Spring 5.x with JEE6-compatible appserver
Does anyone have an experience in that?
As always, Spring Framework upgrades its baseline with new major versions. In this case, we're requiring JDK8+ and Java EE7+.
In practice, this means that the compiled code depends on those APIs and doesn't use reflection anymore to adapt to them. In your case, this is not only about Servlet, but also JPA, JMS, bean validation and other specs.
Your application might work fine with the arrangement you're mentioning, but the Spring team will not guarantee support for this setup.
We have started new project on spring stack and using latest versions. But we have workflow requirement and I used activiti in past. But as I see there is no spring boot 2 support for activiti and camunda. Can anybody suggest which BPM is best that can be integrated with spring boot 2.
You will find a bunch of Spring Boot 2 starters in the Flowable github repo.
The documentation explains step-by-step how to create a BPM enabled Spring Boot application. There is also the blog post The road to Spring Boot 2.0 that the improved support for Flowable within Spring Boot as part of the Flowable 6.3.0 release.
You ask for suggestions on which BPM is best. Well, I cannot be objective since I am part of the Flowable Team, but I can say that our Spring Boot implementation is pretty neat:
All engines are supported (BPMN, CMMN, DMN), both embedded and exposing their respective REST APIs.
There is an automatic configuration of Spring Security to use the Flowable IDM engine (in case no other custom security is configured).
There is no "EE" version of the starter. Flowable provides Spring Boot 2 support 100% Open Source.
The Spring Actuator integration is quite powerful.
Did I mention Open Source? ;-)
In order to get the all engines you would need to use the flowable-spring-boot-starter(-rest) dependency. The (-rest) needs to be used if you want the Flowable REST APIs to be automatically configured.
There is also the option to run the BPMN, CMMN or DMN engines in standalone mode. For that you would need one of the following dependencies:
flowable-spring-boot-starter-process(-rest)
flowable-spring-boot-starter-cmmn(-rest)
flowable-spring-boot-starter-dmn(-rest)
So, compare for yourself, but for me, it's pretty clear and of course I am open to discussion.
The Activiti is working on Activiti Cloud fully based on Spring Boot 2 and Spring Cloud Finchley (targeting kubernetes deployments, but it can be used outside kubernetes if that is not your thing) if you are looking for a BPMN runtime for Cloud Native applications. We are working hard on releasing the first Beta1 release at the moment, and we will very welcome feedback about it. Hope this helps.
If you use the camunda-bpm-spring-boot-starter you can write self contained services running camunda process engine with spring boot 2.
Is there a list of beans provided by Spring Boot and its different modules? For example, I only recently discovered that Spring Boot already provides a configurable Jackson ObjectMapper bean. I would have never known that if not for reading up on an unrelated issue I was dealing with. Now I'm working with Spring JMS and am afraid that I am reinventing the wheel because Spring Boot may already have what I need and I just don't know about it. How are these beans discovered? They don't seem to be cataloged in any Spring documentation.
I would recommend starting with the reference documentation. While it doesn't list every bean that may be auto-configured, it does have documentation describing each feature area that may be auto-configured. For example, there are sections on Jackson's ObjectMapper and on JMS.
Each starter that Spring Boot offers is also a good indication of what it can auto-configure. Each first-party starter is listed in the documentation.
In custom Spring Boot Autoconfiguration projects I usually have some dependencies which are marked as optional. As I need them for compilation, but expect users of my autoconfig to include them manually in their own POM, or they will be provided by the Spring Boot dependencies.
How do I ensure that users of different Spring Boot versions can use my autoconfig without dependecy/version problems?
I see two non-optimal solutions; are there more?
Hoping that the API stays the same
Just hope that the API of my dependencies stays stable over minor version changes, so that if I developed and compiled my Autoconfig e.g. with Spring Boot 1.4.x, the API which I used is still the same with 1.5.x, etc.
I then wouldn't necessarily expect it to work e.g. for Spring Boot 2.x, and would put a corresponding note into the readme.
Explicitly tracking each Spring Boot version
Explicitly build a version for at least each minor Spring Boot version, but possibly even for each Patch version? Who knows when a breaking API change could happen. I would then need to document for which exact Spring Boot version my autoconfig is intended. But this is a lot of work.
Of course Spring Boot's own autoconfig project is developed in lockstep with Spring Boot, so that any problems will be fixed in the same release.
But my own autoconfig might have been developed once and not expect many changes afterwards. How do I ensure that my autoconfig keeps working as long as possible even as the "users" of my autoconfig are updating their Spring Boot version dependencies?
How to set the logging level of embedded tomcat in Spring Boot?
Especially I need to see the tomcat clustering-related logs.
I added the following line to the application.properties, but tomcat seems to log only INFO level logs.
logging.level.org.apache.catalina=TRACE
Is there a simple method to accomplish this?
It would be best to know the Spring Boot and embedded tomcat-specific, simple solution, preferably only editing application.properties.
In short, use Spring Boot version 1.3.0 with Logback. (I was using Spring Boot 1.2.4)
Spring Boot 1.3.0 adds LevelChangePropagator to LogbackLoggingSystem.java (see this commit), thus the logging level that is set in application.properties is propagated to the jul(java.util.logging) which tomcat uses.
Otherwise, one must set the logging level for the logger in the logging.properties for the jul if the level is below the INFO level which is the default, AND also set the logging level for the logger in the application.properties. This is for the limitation of jul-to-slf4j module which cannot completely override jul implementation since jul is in the java.* package.
Also see the following Spring Boot issues: Optimize JUL logging #2585, Slf4JLoggingSystem should also configure JUL levels #2923.
And this is the related StackOverflow question: Spring Boot - set logging level of external jar which is using Java Util Logging (jul). Actually this is the problem I was facing.
(I will accept this answer if no better answer is posted for a few days from now.)