I migrate project from XML Spring Integration configuration to Java DSL. I prepared some integration tests beforehand. So I can do the migration safely step-by-step.
At some point after moving this XML connector definition
<int:publish-subscribe-channel id="upstreamAckChannel" />
to Java Spring Configuration
#Bean
public PublishSubscribeChannel upstreamAckChannel() {
return MessageChannels.publishSubscribe().get();
}
my integration flow stopped resend test messages to my tests.
After some time and experiments I realized that my Spring Java configuration must have #EnableIntegration annotation together with usual Spring #Configuration annotation for properly work.
The question is what is #EnableIntegration annotation semantic? When I can not use it and when I must use?
I could find only this small Configuration paragraph in official reference manual. Unfortunately, description isn't clear.
The PublishSubscribeChannel class exists inside of the Spring Integration project. The #EnableIntegration annotation is used to adopt a default configuration for Spring Integration, so typically when using Spring Integration you'll want to add it (unless you're using a piece of Spring Integration that doesn't require a context--unlikely). The only time you might want to forego it is if you want to do your own configuration from scratch.
Related
I understand that using #SpringbootTest I raise whole spring contex during test, or In my case using #SpringBootTest(classes = SomeController.class) I raise only one bean -> SomeController. If this controller have some dependencies I need to mock them up. Using annotation #WebMvcTest(SoneController.class) I will (based on my knowledge) achieve the same goal.
Question is: Are there any differences between those two annotations used in provided example?
There's a clear difference between #SpringBootTest(classes = SomeController.class) and #WebMvcTest(SomeController.class).
#SpringBootTest(classes = SomeController.class) - starts a server (i.e like Tomcat) + spring application context with the component SomeController.class. In addition to the controller, you should normally specify the context configuration to successfully start the whole app (For ex: when you don't specify the classes, it falls back to #SpringBootApplication).
#WebMvcTest(SomeController.class) - only starts the web layer of the application with SomeController.class.
What's the difference?
#SpringBootTest tests are usually integration tests, you start the full spring-boot application and test against that black box. You can still tweak the application startup by providing configuration, properties, web server type etc in the annotation parameters.
But #WebMvcTest(SomeController.class) is usually a unit test for your controller. These are lightweight and fast. The dependencies like #Service classes are mocked in such tests.
This is a good starting point - https://spring.io/guides/gs/testing-web/
There are several subtle differences between these two ways.
But you will discover a part of them only randomly when you will encounter problems such as bean initialization exception during the spring boot context init or a NullPointerException rising during the test execution.
To make things simpler, focus on intention.
When you write that :
#SpringBootTest(classes = SomeController.class)
you will make Spring to init only the SomeController bean instance.
Is it desirable to test a controller ?
Probably no since you need a way to invoke the controller with a controller approach.
For that a MockMvc instance would help.
With WebMvcTest you get that bean additionally loaded in the test context.
So that way is preferable :
#WebMvcTest(SomeController.class)
public class SomeControllerTest{
#Autowired
private MockMvc mvc;
...
}
Of course you could get a similar behavior with #SpringBootTest and some additional classes but it will be just an overhead : the #WebMvcTest specialized annotation is enough.
At last why make the reading of the test class harder for your follower ?
By weaving a contrived way of using spring boot test annotation, chances are good to come there.
I think for answering your question enough just read the Javadoc for both of these annotations:
1. #WebMvcTest
Annotation that can be used for a Spring MVC test that focuses only on Spring MVC components.
Using this annotation will disable full auto-configuration and instead apply only configuration relevant to MVC tests (i.e. #Controller, #ControllerAdvice, #JsonComponent, Converter/GenericConverter, Filter, WebMvcConfigurer and HandlerMethodArgumentResolver beans but not #Component, #Service or #Repository beans).
By default, tests annotated with #WebMvcTest will also auto-configure Spring Security and MockMvc (include support for HtmlUnit WebClient and Selenium WebDriver). For more fine-grained control of MockMVC the #AutoConfigureMockMvc annotation can be used.
#SpringbootTest
Annotation that can be specified on a test class that runs Spring Boot based tests. Provides the following features over and above the regular Spring TestContext Framework:
Uses SpringBootContextLoader as the default ContextLoader when no specific #ContextConfiguration(loader=...) is defined.
Automatically searches for a #SpringBootConfiguration when nested #Configuration is not used, and no explicit classes are specified.
Allows custom Environment properties to be defined using the properties attribute.
Allows application arguments to be defined using the args attribute.
Provides support for different webEnvironment modes, including the ability to start a fully running web server listening on a defined or random port.
Registers a TestRestTemplate and/or WebTestClient bean for use in web tests that are using a fully running web server.
I'm trying to write a integration test for my SpringBoot microservice that interacts with another service inside the product ecosystem.
Since this kind of testing is consider function/integration testing (depending on what nomenclature you use) it is usually done on some development environment.
However, I wanted to test a basic interaction between my service and a STUB/dummy app which are connected with RPC (so not exactly a typical TestRestTemplate test).
I know that there is a way to embed a service while booting up the Spring Context but have never done it by myself.
Does anyone have any experience with the upper or maybe a few helpful links where I can explore.
I have used WireMock in tests to mock services external to what I want to test that communicate over HTTP.
My test class annotated with #SpringBootTest is also annotated with #ContextConfiguration. In the classes attribute #ContextConfiguration I explicitly specify the configuration classes required to set up the Spring Context for the test in question. Here I can also include additional configuration classes in which I create beans only used in the test. In test configuration classes I can also override beans for the purpose of the test, creating mock beans etc.
Note that Spring Boot 2.1 and later disables bean overriding by default. It can be enabled by setting the following property to true:
spring.main.allow-bean-definition-overriding=true
To set the property for a single test, use the #TestPropertySource annotation like this:
#TestPropertySource(properties = {
"spring.main.allow-bean-definition-overriding=true"
})
TL;DR
Is there a way to mix Spring Web Security configuration with both annotations and xml?
Full Story
For our legacy spring web application we are looking into using annotation driven configuration for part of our web security.
Currently all our web security (<security:http>) is driven by xml based configuration. But we are adding a new login mechanism (SAML 2.0) that seems like it would be much easier to configure via annotations than xml.
We have been attempting to mix the use of annotations and xml, but it seems as though only one or the other works. Meaning that when any xml based web security is referenced, either via an xml (<import resource="classpath:web-security.xml"/> or via the #ImportResource annotation, the annotation based web security is ignored.
If we remove references to the xml based configuration our annotation configuration gets called.
Any friendly suggestions or advice is appreciated.
Mixing the Spring Web Security XML and annotation configurations would mean that that the same bean instance, viz., security:http is being configured via XML as well as JavaConfig. It would be configured with some intercept URL patterns using XML and some other Ant matchers using JavaConfig. But please note that intercept URL patterns are always evaluated in the order they are defined and also the matchers are considered in order. So, Spring Security only considers the XML configurations and ignores the JavaConfig ones as, if it considers both, it won't have any sense of order of URL definitions. I couldn't find any documentation that directly supports this theory. If you share the Spring Boot log statements that are produced when the application boots up, we may get a better view of what Spring Boot is doing.
So, I don't think that you can mix Spring Annotations with XML Configuration when configuring Spring Web Security and will advise to migrate legacy XML configurations to JavaConfig.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am beginner for Spring Boot. When I am using any dependencies in Spring Boot, they have the auto configuration default.
My questions are:
What is actually auto configuration class?
How does auto configuration work?
How to make out own auto configuration?
Please suggest me any blog that describes easy manner or please provide me any code snippet for better understanding.
The Spring Boot core package spring-boot-starter contains the spring-boot-autoconfigure package.
What does it do? (from the JavaDoc)
Enable auto-configuration of the Spring Application Context,
attempting to guess and configure beans that you are likely to need.
Auto-configuration classes are usually applied based on your classpath
and what beans you have defined. For example, If you have
tomcat-embedded.jar on your classpath you are likely to want a
TomcatEmbeddedServletContainerFactory (unless you have defined your
own EmbeddedServletContainerFactory bean).
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. Auto-configuration
is always applied after user-defined beans have been registered.
So each jar in your classpath that Spring can autoconfigure, Spring will autoconfigure for you to use in your application. Think about Hibernate, ThymeLeaf, Jackson etc.
How do you use it?
Simply add the #EnableAutoConfiguration in your application to make Spring autoconfigure your application (you possibly also need #SpringBootConfiguration).
#SpringBootConfiguration
#EnableAutoConfiguration
// Or just #SpringBootApplication instead of the 2 above
#Import(AppConfig.class)
public class App {
public static void main(String[] args) {
SpringApplication.run(App.class);
}
}
And your good to go.
What can it configure for you?
All of these tools below (got this from looking at the org.springframework.boot.autoconfigure package)
admin
amqp
aop
batch
cache
cassandra
cloud
condition
context
couchbase
dao
data
analyzer
domain
jest
flyway
freemarker
template
gson
h2
hateoas
hazelcast
info
integration
jackson
jdbc
jersey
jms
jmx
jooq
kafka
ldap
liquibase
logging
mail
mobile
mongo
mustache
jpa
reactor
security
sendgrid
session
social
solr
template
thymeleaf
transaction
validation
web
webservices
websocket
How to create your own configuration?
Don't know, never needed to do this. But this blog is a good starting point.
I started using Ehcache in my Spring Boot project. How can I prove that the Ehcache is being used instead of the default ConcurrentHashMap, which is provided by Spring Boot by default? How can I prove it automatically in the integration tests?
If I understand the question correctly, you are trying to validate your spring configuration.
A one time thing regarding Ehcache is to check logs - you should see the information about it being started and configured.
For automated testing, the easiest way is going to be to have the test configured to be injected with the cacheManager bean and then making sure it is of the right type.
This should give you the confidence that your setup is correct.