I'm totally new to Kafka and terribly confused by this:
https://docs.spring.io/spring-kafka/reference/html/#with-java-configuration-no-spring-boot
I don't understand what that even means. What does "no spring boot mean" because that example sure as hell uses spring boot. I'm so confused....
EDIT
if I'm using SpringBoot and spring-kafka, should I have to manually create #Bean ConcurrentKafkaListenerContainerFactory as shown here. Most of the examples in the docs for setting up filtering / config / etc seem to use the "manual" configuration using #Bean. Is that "normal"? The docs are very confusing to me...especially this warning:
Spring for Apache Kafka is designed to be used in a Spring Application Context. For example, if you create the listener container yourself outside of a Spring context, not all functions will work unless you satisfy all of the …Aware interfaces that the container implements.
It's referring to the autowired configuration, as compared to putting each property in the config via HashMap/Properties in-code.
Also, it does not use #SpringBootApplication or SpringApplication.run, it just calls a regular main method using a hard-coded Config class.
Spring boot contains the functionality of AutoConfiguration
What this means is that spring boot when discovers some specific jar dependencies it knows, in the project, it automatically configures them to work on a basic level. This does not exist in simple Spring project where even if you add the dependency you have to also provide the configuration as to how it should work in your application.
This is also happening here with dependencies of Kafka. Therefore the documentation explains what more you have to configure if you don't have spring-boot with auto-configuration to make kafka work in a spring project.
Another question asked in comment is what happens in case you want some complex custom configuration instead of the automatic configuration provided while you are in a spring-boot app.
As documented
Auto-configuration tries to be as intelligent as possible and will
back-away as you define more of your own configuration. You can always
manually exclude() any configuration that you never want to apply (use
excludeName() if you don't have access to them). You can also exclude
them via the spring.autoconfigure.exclude property.
So if you want to have some complex configuration which is not automatically provided by spring-boot through some other mechanism like a spring-boot specific application property, then you can make your own configuration with your custom bean and then either automatic configuration from spring-boot for that class will back of as spring does several intelligent checks during application context set up or you will have to exclude the class from auto configuration manually.
In that case you could probably take as an example reference of how to register manually your complex configurations in spring boot what is documented on how to be done in non spring boot app. doc
Related
And most important, what's the reason behind the "Auto" prefix? Classes annotated with #Configuration rather than #AutoConfiguration are less automatic or something?
#Configuration is a spring framework annotation and not strictly bound to spring-boot. It was introduced when spring started to allow programmatic creation of spring-beans as to move forward from xml definitions of beans.
#AutoConfiguration is a spring-boot specific annotation not commonly available in spring framework. The reason it exists, is for external providers that cooperate with spring-boot to be able to mark some classes in some libraries they provide with this annotation as to inform spring-boot that those classes could be parsed and make some initializations during start up of spring application automatically.
So if some regular programmer that develops some application happens to have kafka in dependencies then some beans will automatically be created and added in application context and will be ready for the programmer to use, although he has not defined any configuration for them. Spring-boot already knows this as the kafka provider has already informed by marking some class in the jar they provide with the annotation #AutoConfiguration.
For this reason #AutoConfiguration has some more powerful configurations available as before, after, beforeName, afterName as to allow the provider to specify when the configuration is applied during application startup if some order is necessary.
So this annotation is not to be used from some regular programmer that develops an application using spring-boot. It is for someone that develops a library that other users might use with spring-boot. One such example is kafka library.
For this to work in a spring-boot project #EnableAutoConfiguration is needed as well, to enable auto configuration.
From spring documentation
Spring Boot auto-configuration attempts to automatically configure
your Spring application based on the jar dependencies that you have
added. For example, if HSQLDB is on your classpath, and you have not
manually configured any database connection beans, then Spring Boot
auto-configures an in-memory database.
#Configuration instead is to be used from some regular programmer that develops an application using spring-boot or spring-framework as to inform the framework for which beans should be created and how.
#AutoConfiguration was introduced in 2.7 with the idea to mark all auto-configurations with its dedicated annotation and move away from spring.factories for auto-configuration imports in 3.0 as described in Github issue.
According to Spring documentation:
[#AutoConfiguration] indicates that a class provides configuration that can be
automatically applied by Spring Boot. Auto-configuration classes are
regular #Configuration with the exception that
Configuration#proxyBeanMethods() proxyBeanMethods is always false.
Usually, #AutoConfiguration classes automatically configure an application based on the dependencies that are present on the classpath. Those classes are generally marked as #ConditionalOnClass and #ConditionalOnMissingBean annotations that detect the presence or absence of specific classes.
Additionally, if a configuration needs to be applied in a specific order, you can use the before, beforeName, after, and afterName attributes on the #AutoConfiguration, unlike #Configuration which doesn't provide those attributes.
I have been using Spring Boot and Spring Cloud for a while, and Spring core for even longer, yet I cannot find a clear rule on which technique to use when creating a framework :
Spring Boot starter + spring.factories file
Spring Boot starter + #EnableXxx
both
For example :
the Eureka client starter requires users to import spring-cloud-starter-eureka-client AND to add #EnableEurekaClient on some configuration class
On the other hand, adding spring-boot-starter-jdbc on the classpath is enough to trigger data source auto configuration. There is no such thing as #EnableDataSourceAutoConfiguration
Somebody who wants to configure caching through configuration properties also needs to add #EnableCaching manually
Sometimes the #EnableXxx annotated class is included in the code brought by a starter, sometimes not.
I know #Enable... is the "pre Spring-Boot" method (technically a good-looking #Import), but the fact that #EnableEurekaClient exists is proof that it's not deprecated by any mean.
What's the rule there ? I can't find it in the docs.
There's no hard and fast rule (at least from the Spring Cloud perspective).
Dave Syer said:
A candidate rule of thumb is "if something is on the classpath but
provides multiple features, you need a way to switch on a subset"
I prefer to think of it as "revealing a conscious choice"
as opposed to "relying on magic"
I've kind of looked at as starting servers or doing work (like Discovery Client)
I work on a corporate Spring Boot extension that autoconfigures its own RabbitMQ clients. This extension (a starter) replaces the Spring Boot RabbitAutoConfiguration.
I know there are many ways to disable the RabbitAutoConfiguration :
in each Application (main) class with #EnableAutoConfiguration(exclude = RabbitAutoConfiguration.class) or #SpringBootApplication(exclude = RabbitAutoConfiguration.class)
in the application.properties or yml file (externalized or within the jar), with spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration
I wonder if there is a way that the presence of my new starter disables the Spring Boot RabbitAutoConfiguration.
I tried some dirty things, such as putting an application.properties with the exclude property in the corporate starter module, but as Spring Boot only reads one in the classpath, it can be easily overriden by one used in a client application. I do not want to impose some restrictions.
I do not like the idea of each application adding the same exclusion one way or the other (properties or annotation).
Any ideas ?
EDIT
I need to configure several RabbitMQ ConnectionFactory and RestTemplate within the same application.
If you want to truly replace the standard RabbitAutoConfiguration by yours, you just need to add #AutoconfigureBefore(RabbitAutoConfiguration.class) on your own auto-configuration to teach Spring Boot to process yours before the standard one.
If it is a replacement, yours will register beans that the standard auto-configuration will detect and it will back-off the same way as if you would have defined them manually.
Having said that, why are you doing this? I'd rather complement the existing auto-configuration rather than replacing the standard one. Is there a problem with the standard one? If so, we'd love to hear about it and adapt the code so that you don't have to fully replace it.
tl/dr (How) Is it possible to use a jar library, that uses Spring Boot for configuration in a non Spring Boot (regular old-school Spring) server.
We have the problem, that we have a Spring server, that is from the pre-Boot times and we want to create a new library for it. We would like to use Spring Boot in the library (i.e. #EnableAutoConfiguration for configuration). To include the library we have put an spring.xml into the library that enables component-scan inside the library. The classes inside the library use #EnableAutoConfiguration and #EnableWebSecurity to enable configuration and security.
If we include now the library into our server and import the XML file from the library into the server's XML file, only parts of the configuration are working. The #RequestMappings in the library are working and the interfaces are available. However Spring security fails to register it's default filter chain, leading to ugly errors, where the regular Spring Boot config should already work with AnonymousAuthorizationFilter, etc.
We debugged, that the FilterRegistrationBean in spring security is never configured when running that way (and is, if we are running as a Spring Boot application).
So is there a common way how to deal with Spring Boot enabled libraries inside old-school Spring servers?
Is placing a single XML to enable component-scan in the library and importing this XML inside the main server's XML the correct way to include Spring Boot libraries (and how would be the best way, if the server would use Spring Boot itself)?
Does anyone know of the issue with a missing Spring Security filter chain?
PS: I know that we can add the required filters manually. However if we would do that, we would anyway get rid of Spring Boot completely in the library, so this question mainly aims for how to do it with Spring Boot. Of course if it is the wrong way to enable Spring Boot inside a library, please also mention that :-)
I'm trying to implement external session handling in Spring, as per this tutorial. I'm having some trouble adding the right filter though. Spring Boot appears to have defined the proper bean/filter, but my project is not Spring Boot, so it cannot find the FilterRegistrationBean. Is there some sort of equivalent to this class in non-Boot versions of Spring? I also tried org.springframework.web.context.embedded.FilterRegistrationBean, but can't get it to import properly (it looks like this documentation refers to a SNAPSHOT version, so perhaps this package was never part of a proper release).
Depending on your container configuration, web.xml or ServletContainerInitializer, you can register a DelegatingFilterProxy filter and make it refer, by name, to a Filter bean you've declared in your ApplicationContext.