Short description of the problem :
I wrote a simple HTTP REST interface built using Spring Boot, which returns a simple text response when calling GET /app based on the ClientInterface implementation, of which 2. REST capabilities implemented using JAX-RS, provided by restyling through the RestEasy-SpringBoot library .
I also wrote 3 tests, of which the 3rd error, because the answer comes from the second ClientInterface implementation instead of the first implementation, because (I suppose) Resteasy mixes the application instances, and therefore the wrong Spring application context is loaded with the wrong beans .
NOTE : here you can find an example application that also includes documentation
Please see the source code for a clear image. It would also take up too much space to insert code.
Additional information :
There are 2 ClientInterface implementations that provide the response provided by the REST resource. They switch using the client-impl-two profile. If there is no profile, the first implementation is used, if it is present, the second is used.
The first and third tests are waiting for a response from the first implementation, and the second test is waiting for a response from the implementation of seconds, because it uses the client-two-impl .
When I run tests using JUnit integration from IntelliJ, the third error: 
You will notice that the tests are named so that it applies a specific order of execution, which is important because the third test fails if it is executed AFTER the second. And it does not work because it received a response from the second implementation of ClientInterface , although the third test does NOT use the client-impl-two profile.
What I have done / discovered so far :
- sometimes running
./mvnw clean test also has the same error results, but I could not provide a reproducible example - Spring application context loaded correctly Spring / Spring Boot
- Spring Boot correctly enters the port number, and the rest of the client in the tests always calls the REST instance that they should use
- only when Resteasy takes on the request that it somehow loads the wrong instance of the application, and therefore, the wrong Spring application context is used, so it gives the wrong answer
- I realized this by storing a breakpoint in SpringResourceFactory.createResource (), where it simply queries
beanFactory for the bean resource and calls beanFactory.getBean(ClientInterface.class) to see which implementation occurred, and this was not true for the third test
- during the tests, there is more than one instance of the application, each of which has its own port, which, I believe, has something to do with the problem.
- there is another branch of
jersey-instead-of-resteasy , in which Jersey is used as an implementation of JAX-RS, and where the tests are successful, regardless of whether they are run with IntelliJ or with Maven - there is a
DebugFilter with which I check what the Spring application context looks like before the request is passed by the Resteasy servlet and it is always correct (the correct ClientInterface implementation is loaded), regardless of how the test runs- this is only when starting the third test, and when the request reaches Resteasy, the wrong application instance is loaded, as indicated in one of the points above.
Based on the points above, I have a strong suspicion. There may be a problem with Resteasy.
Any help is greatly appreciated.