Tests failed when 'boot-java.live-information.automatic-connection.on' turns on

[Tazaf]

OK, I have a weird issue in one of the project on which I'm working. I'm not exactly sure what's causing it and I'm not sure that this extension is really responsible.

But since the symptoms appear when using the Test Explorer of this extension, it seems like a good place to start.

I work on a Spring Boot application (currently 2.6.5) which have a test suite. When I run this test suite by executing mvn test in the command line, it runs completely and all the tests pass. But when I run the same test suite by clicking the following icon:

Then, some of the tests fail with the following stacktrace:

Error StackTrace Details

java.lang.IllegalStateException: Failed to load ApplicationContext
 at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext([DefaultCacheAwareContextLoaderDelegate.java:132](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java%3A132)%22%2C%22achille%22%5D))
 at org.springframework.test.context.support.DefaultTestContext.getApplicationContext([DefaultTestContext.java:124](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java%3A124)%22%2C%22achille%22%5D))
 at org.springframework.test.context.web.ServletTestExecutionListener.setUpRequestContextIfNecessary([ServletTestExecutionListener.java:190](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.test.context.web.ServletTestExecutionListener.setUpRequestContextIfNecessary(ServletTestExecutionListener.java%3A190)%22%2C%22achille%22%5D))
 at org.springframework.test.context.web.ServletTestExecutionListener.prepareTestInstance([ServletTestExecutionListener.java:132](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.test.context.web.ServletTestExecutionListener.prepareTestInstance(ServletTestExecutionListener.java%3A132)%22%2C%22achille%22%5D))
 at org.springframework.test.context.TestContextManager.prepareTestInstance([TestContextManager.java:248](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java%3A248)%22%2C%22achille%22%5D))
 at org.springframework.test.context.junit.jupiter.SpringExtension.postProcessTestInstance([SpringExtension.java:138](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.test.context.junit.jupiter.SpringExtension.postProcessTestInstance(SpringExtension.java%3A138)%22%2C%22achille%22%5D))
 at java.base/java.util.stream.ReferencePipeline$3$1.accept(Unknown Source)
 at java.base/java.util.stream.ReferencePipeline$2$1.accept(Unknown Source)
 at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(Unknown Source)
 at java.base/java.util.stream.AbstractPipeline.copyInto(Unknown Source)
 at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(Unknown Source)
 at java.base/java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining(Unknown Source)
 at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Unknown Source)
 at java.base/java.util.stream.Streams$ConcatSpliterator.forEachRemaining(Unknown Source)
 at java.base/java.util.stream.ReferencePipeline$Head.forEach(Unknown Source)
 at java.base/java.util.Optional.orElseGet(Unknown Source)
 at java.base/java.util.ArrayList.forEach(Unknown Source)
 at java.base/java.util.ArrayList.forEach(Unknown Source)
Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'springApplicationAdminRegistrar' defined in class path resource [org/springframework/boot/autoconfigure/admin/SpringApplicationAdminJmxAutoConfiguration.class]: Invocation of init method failed; nested exception is javax.management.InstanceAlreadyExistsException: org.springframework.boot:type=Admin,name=SpringApplication
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean([AbstractAutowireCapableBeanFactory.java:1804](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java%3A1804)%22%2C%22achille%22%5D))
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean([AbstractAutowireCapableBeanFactory.java:620](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java%3A620)%22%2C%22achille%22%5D))
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean([AbstractAutowireCapableBeanFactory.java:542](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java%3A542)%22%2C%22achille%22%5D))
 at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0([AbstractBeanFactory.java:335](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.AbstractBeanFactory.lambda%24doGetBean%240(AbstractBeanFactory.java%3A335)%22%2C%22achille%22%5D))
 at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton([DefaultSingletonBeanRegistry.java:234](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java%3A234)%22%2C%22achille%22%5D))
 at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean([AbstractBeanFactory.java:333](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java%3A333)%22%2C%22achille%22%5D))
 at org.springframework.beans.factory.support.AbstractBeanFactory.getBean([AbstractBeanFactory.java:208](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java%3A208)%22%2C%22achille%22%5D))
 at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons([DefaultListableBeanFactory.java:953](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java%3A953)%22%2C%22achille%22%5D))
 at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization([AbstractApplicationContext.java:918](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java%3A918)%22%2C%22achille%22%5D))
 at org.springframework.context.support.AbstractApplicationContext.refresh([AbstractApplicationContext.java:583](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java%3A583)%22%2C%22achille%22%5D))
 at org.springframework.boot.SpringApplication.refresh([SpringApplication.java:734](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.boot.SpringApplication.refresh(SpringApplication.java%3A734)%22%2C%22achille%22%5D))
 at org.springframework.boot.SpringApplication.refreshContext([SpringApplication.java:408](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java%3A408)%22%2C%22achille%22%5D))
 at org.springframework.boot.SpringApplication.run([SpringApplication.java:308](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.boot.SpringApplication.run(SpringApplication.java%3A308)%22%2C%22achille%22%5D))
 at org.springframework.boot.test.context.SpringBootContextLoader.loadContext([SpringBootContextLoader.java:132](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.boot.test.context.SpringBootContextLoader.loadContext(SpringBootContextLoader.java%3A132)%22%2C%22achille%22%5D))
 at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal([DefaultCacheAwareContextLoaderDelegate.java:99](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java%3A99)%22%2C%22achille%22%5D))
 at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext([DefaultCacheAwareContextLoaderDelegate.java:124](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java%3A124)%22%2C%22achille%22%5D))
 ... 71 more
Caused by: javax.management.InstanceAlreadyExistsException: org.springframework.boot:type=Admin,name=SpringApplication
 at java.management/com.sun.jmx.mbeanserver.Repository.addMBean(Unknown Source)
 at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(Unknown Source)
 at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(Unknown Source)
 at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(Unknown Source)
 at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(Unknown Source)
 at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(Unknown Source)
 at org.springframework.boot.admin.SpringApplicationAdminMXBeanRegistrar.afterPropertiesSet([SpringApplicationAdminMXBeanRegistrar.java:129](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.boot.admin.SpringApplicationAdminMXBeanRegistrar.afterPropertiesSet(SpringApplicationAdminMXBeanRegistrar.java%3A129)%22%2C%22achille%22%5D))
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods([AbstractAutowireCapableBeanFactory.java:1863](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java%3A1863)%22%2C%22achille%22%5D))
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean([AbstractAutowireCapableBeanFactory.java:1800](command:_java.test.openStackTrace?%5B%22%5Ctat%20org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java%3A1800)%22%2C%22achille%22%5D))
 ... 86 more

Here's what I have found so far:

• All the failing tests belong to classes that extend a BaseIntegrationTestClass that has @SpringBootTest (and other annotations, see below), but not all those classes extending BaseTestIntegrationClass have their test fail.
• If I run the failing tests separately afterward, they all pass (wether it be by running the test itself, or all the tests in the same class).
• If I rerun the complete test suite, the failing tests won't necessarily be the same as in the previous run (but they will always be @SpringBootTest)

Here's what I tried so far:

• Cleaning the java workspace with Java: Clean Java Language Server Workspace the running the test suite again produces the same result (event restarting the computer doesn't change the outcome...)
• Have a colleague of mine clone the repository on their computer and run the test suite through the Test Explorer on their VS Code. In this case, they didn't encounter the issue.
• Again, running the test suite with mvn test pass without issue.

`BaseIntegrationTestClass` annotations

@ExtendWith(SpringExtension.class)
@SpringBootTest
@Import({ /* some classes */ }
@Transactional
@ActiveProfiles({ /* some profiles */ })
@AutoConfigureMockMvc
public class BaseIntegrationTestClass {
    /* class implementation */
}

I don't really know if all of this will help you, but if any of you have any hints or idea as to why this behavior happens, I'll take anything.

Thanks in advance, and I'll happilly provide any additional information if necessary.

[jdneo]

Have a colleague of mine clone the repository on their computer and run the test suite through the Test Explorer on their VS Code. In this case, they didn't encounter the issue.

Considering other people do not have the same problem, is that possible that some environment related things causing the problem? Like the environment variables?

[Tazaf]

Yes, I'm pretty sure there's something in my environment that messes with those test runs. No idea what could, though.

Like the environment variables?

Any hint as to what kind of environment variable I should look for? I've printenv them but nothing looked suspicious. Maybe some kind of setting in VS Code itself?

That reminds me... I forgot to add that I'm running all my dev tools on WSL2 for Windows. Not sure that should change anything, but it's worth mentionning.

[yotov]

Same problem for me ( I'm using VSCode under MacOS ). After some debugging I found that the bug is caused by boot-java.live-information.automatic-connection.on setting which is provided by vscode-spring-boot extension but I'm not sure what is the problem with it.

[jdneo]

Oh thank you @yotov for reminding this!

We encountered this issue before: https://github.com/microsoft/vscode-java-test/issues/1420#issuecomment-1132829069

@Tazaf could you check if disable boot-java.live-information.automatic-connection.on can solve your problem?

[Eskibear]

AFAIK vscode-spring-tools will append some vmArgs when this setting is on.

Not sure whether that's related or conflict with test runner. //also cc @martinlippert @BoykoAlex for awareness.

[Tazaf]

@Tazaf could you check if disable boot-java.live-information.automatic-connection.on can solve your problem?

@jdneo Well, it actually does 😄 With this setting disabled, the test suite is all green when launched via the Test Explorer.

[BoykoAlex]

I'll give this a try

[BoykoAlex]

@Tazaf any chance you can attach some simplified version of your project that reproduces the issue? I've tried running the tests from spring-petclinic project with boot-java.live-information.automatic-connection.on enabled and the tests seems to run fine

[Tazaf]

Well... I can try, but I don't know when I will find the time to do so, as the following weeks are pretty busy for me.

I'll keep you posted 👍

Le jeu. 23 juin 2022 à 17:11, Alex Boyko @.***> a écrit :

@Tazaf https://github.com/Tazaf any chance you can attach some simplified version of your project that reproduces the issue? I've tried running the tests from spring-petclinic project with boot-java.live-information.automatic-connection.on enabled and the tests seems to run fine

— Reply to this email directly, view it on GitHub https://github.com/microsoft/vscode-java-test/issues/1435#issuecomment-1164535997, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB2YOMS7LSATLHTZHPH3RY3VQR5AVANCNFSM5YJXWQ3Q . You are receiving this because you were mentioned.Message ID: @.***>

[Eskibear]

The most likely reason I can think of is that live connection occupies some ports which are required for testing. So, another idea is, if the debug session is a "test" session, spring tools extension simply does not connect to live process.

E.g. Mark something in launch configs when testing sessions launched from Test Runner extension. And spring tools extension simply change below method a little bit, also checking corresponding marks.

https://github.com/spring-projects/sts4/blob/71b08e0c34dd5e82fff32017de01b6d3c845ae14/vscode-extensions/vscode-spring-boot/lib/debug-config-provider.ts#L124-L131

[BoykoAlex]

@Eskibear Sounds good to me. I can disable "auto-connect" for live running process if it is a test launch, i.e if 'org.eclipse.jdt.internal.junit.runner.RemoteTestRunner' !== debugConfig.mainClass - if this seems like a good enough condition to you i can make this change on the Boot Tools vscode extension side.

[jdneo]

Hi @BoykoAlex,

It could be two main classes when launching tests.

• org.eclipse.jdt.internal.junit.runner.RemoteTestRunner for JUnit tests
• com.microsoft.java.test.runner.Launcher for TestNG tests

Besides comparing the main class name, maybe the test runner extension can add a new field to specify whether this is a test launch in the launch configuration - in case that the main class name changes in the future which will break the feature again. Maybe something like:

_vscode_java_test_launch_: boolean

So it could be

if (debugConfig._vscode_java_test_launch_ ||
    'org.eclipse.jdt.internal.junit.runner.RemoteTestRunner' === debugConfig.mainClass ||
    'com.microsoft.java.test.runner.Launcher' === debugConfig.mainClass) {
    // disable auto-connect
}

In the future once most users have updated to new version of the extensions, we can remove the main class name check. WDYT?

[Eskibear]

I myself would perfer the main class check for two reasons.

• Class name for test frameworks are relatively stable and won't change very often. We can maintain a whitelist of main classes for popular test frameworks.
• AFAIU the mark _vscode_java_test_launch_ is only added when it's launched by vscode-java-test extension, and spring extension's monitoring all 'java' debug sessions. If anyone manually specify the test session in launch.json and launch it with F5, the mark won't be added.

So I'd like to check something like testFrameworkMainClasses.includes(debugConfig.mainClass) in spring extension. That also avoids spring extension to refer something invented by vscode-java-test extension. @jdneo Any other concern/disadvantage for the approach?

[jdneo]

So far, we do not expose the launch configuration for test in the launch.json, but anyway, only check the main class name looks good to me as well. Since the implementation is straightforward and the cost is quite small.

[BoykoAlex]

Based on our discussion above I've pushed the fix for boot ls: https://github.com/spring-projects/sts4/commit/ec8a5a87ba5b06e8bb4e0fd6ef71405ab1cd0b34

[jdneo]

Close since the issue should have been fixed upstream.