The binding issue when using "run as Spring Boot App" of Spring Tool Suite 4

[jerryxcy]

[Symptom]
When I use the latest Spring Tool Suite 4.01 to run the sample application of spring-cloud-stream,
I found that when I use the "run as Spring Boot App" instead of "run as Java application", the application
will not connect the rabbitmq server to create exchange and queue.
It appears it's a issue of Spring Tool Suite. Because there is no any exception log, I spent some time to find
if there is anyone encounter the same issue but no finding.
Luckily, I found when I comment the following dependency in build.gradle, it works!
//testImplementation('org.springframework.cloud:spring-cloud-stream-test-support')
The exchange and queue will be created when run as Spring Boot App.
Because the project is created by spring initializr, the dependency testImplementation('org.springframework.cloud:spring-cloud-stream-test-support') is automatically
added by default, I guess the compatablity is confirmed.
Could you help take a look if it's a issue of 'org.springframework.cloud:spring-cloud-stream-test-support'
library? Because there is no any exception log, it's hard to find the root cause from user.

[sample code for reproduce]
https:/hyderai/TestSpringCloudStream

[olegz]

That is most likely because the test binder is picked up as default (instead of the Rabbit). . . but we'll take a look if here is anything that can be done

[sabbyanandan]

@aclement: When you get a chance, could you or someone from the STS team have a look at this?

[bboeck]

I'm quite sure that the problem is caused by STS. I ran into the same problem. A colleague ran my code on his mac using IntelliJ and there it was working.

[olegz]

Please raise the issue with STS team. Feel free to link to this one. Meanwhile I will close it since there is nothing we can do on our end.

[kdvolder]

Gradle? If the answer is yes, I suspect it is a classpath related issue. The runtime classpath for gradle project's in Eclipse is not allways the same as when run through the commandline.

In fact I recently fixed something to make this better. So it may be worthwhile to try out an STS snapshot build to see if it helps. Please refer to this issue for details: spring-attic/spring-ide#264

[bboeck]

Today I tried the latest nightly build (3.9.8.201901302038-CI-B2145) and the problem still exists.

[garyrussell]

It's designed that way; if the test binder is on the class path, it will replace the real binder. You need to exclude it from tests that need to use the real binder.

See the documentation.

[kdvolder]

@bboeck If you tried to update STS from a update site, I wouldn't necessarily trust that it will update everything correctly. Please try a full distribution build. You can download one here: http://dist.springsource.com/snapshot/STS4/nightly-distributions.html (pick one under "Eclipse-based distribution builds" section).

Also I should mention that the fix I referred above will only take effect on new launch configurations. If you are using an old workspace you may be using old launch configuration, these old launch configurations will still behave the same way as before the bugifx.

So to sumarize, the latest STS "Run As >> Spring Boot App" functionality should use the exact same classpath as when using BuildShip directly (i.e. "Run As >> Java Application"), but only for new launch configurations.

It is still possible the bugfix is buggy. So, if all of the following are true:

a) you are using a full nightly distribution build
b) you are using newly created launch configurations
c) what you are trying to do is working correctly when running via "Run As >> Java Application"
d) but is not working correctly when running via "Run As >> Spring Boo App"

If all of these are true, then the conclusing must be that either our bugfix is not working properly, or the bug you are experiencing is a different bug then we assumed. Then, please raise a ticket with STS 4 (https:/spring-projects/sts4) and please make sure to include enough details that we can reproduce and debug the issue. The best would be to attach a sample project that we can run, along with a short description what the expected correct and observed incorrect behavior is.

For the moment, I think the most likely reason why you are still seeing the bug is because you are probably still using old launch configuration(s) with incorrect classpath(s).

[bboeck]

@kdvolder I have just installed spring-tool-suite-4-4.1.2.CI-B1528-e4.11.0-win32.win32.x86_64.zip and the problem seems to be solved. Everything is working fine now.

Thx for your help!

[kdvolder]

@bboeck Glad to hear that, thanks for letting us know!