Multiple containers for `@Nested` classes

[nlisker]

When testing with @Nested classes, Weld initiates a container for each nested level. Could be related to #288, though this is regardless of @TestInstance(Lifecycle.PER_CLASS).
For example:

@EnableAutoWeld
public class WeldTest {

	@Nested
	class A {

		@Test
		void a() {
			System.out.println("a");
		}

		@Nested
		class A2 {

			@Test
			void a() {
				System.out.println("a");
			}
		}
	}

	@Nested
	class B {

		@Test
		void a() {
			System.out.println("a");
		}
	}
}

will start 3 containers: for WedTest, A and A2. Removing B does nothing. This causes a warning in more complicated cases:

org.jboss.weld.environment.se.WeldSEProvider getCDI
INFO: WELD-ENV-002006: Multiple containers running - CDI.current() may not work properly

Is this the correct behavior? I'd assume the same container can be used here.

[manovotn]

Could be related to #288, though this is regardless of @testinstance(Lifecycle.PER_CLASS).

This is a different problem and PER_CLASS lifecycle doesn't affect it as this spans across several test classes.

A little bit of explanation:

@Nested tests are generally a pain - CDI doesn't like nested classes as they cannot be a bean and JUnit handling of them can be cumbersome.

As for the problem at hand, I vaguely recall that there is an issue with knowing if you should or shouldn't start a CDI container from within the extension for currently processed test class.
In your case, when JUnit tries to execute a test for A2, you don't want to start container for WeldTest or A.
This is because you don't know all the beans you want to add to the that given test deployment - for that you need to start from the nested class (A2) and scan that one (and possibly the declaring class(es)). And we try to do that.

However, in the Junit extension, you get notified for each test class being processed, starting with the outermost one (WeldTest -> A -> A2), and there is no telling if that class has actual tests[1] or if it's being created just as a prerequisite[2] for the nested test class. If it's the former, we want to start the container but if it's the latter, we want to skip it. Last time I checked, I didn't find a way to determine that 🤷

If you want to give it a go and send a PR, I'll be happy to assist.

Last but not least, while the current behavior isn't correct per se, it shouldn't affect your tests.
Are you seeing any failures because of that?

[nlisker]

Thanks as always for the detailed explanation. My real test case hooks up with JPA (hibernate) and JTA (narayana) to be able to test with entities and transactions. I noticed that entities that are persisted in one "class level" are not present in a nested level, e.g.:

@EnableAutoWeld
@AddPackages(...)
class ResourceTest {

	@Inject
	EntityManager entityManager;

	@BeforeAll
	void init() {
		entityManager.getTransaction().begin();
		entityManager.merge(new UserAccount(3));
		entityManager.getTransaction().commit();

		UserAccount user = entityManager.find(UserAccount.class, 1); // finds correctly
	}

	@Nested
	class Sub {

		@BeforeAll
		void initSub() {
			UserAccount user = entityManager.find(UserAccount.class, 1); // finds nothing
		}
	}
}

which means that I can't easily propagate state through nested levels, which somewhat defeats the purpose of nested classes.

I don't know if Weld is responsible for the initialization of JPA/JTA here, but after every time Weld starts, Hibernate and Arjuna start too:

Nov 06, 2025 2:50:30 PM org.hibernate.jpa.internal.util.LogHelper logPersistenceUnitInformation
INFO: HHH000204: Processing PersistenceUnitInfo [name: test_pu]
Nov 06, 2025 2:50:30 PM org.hibernate.resource.beans.spi.ManagedBeanRegistryInitiator interpretImplicitCdiBeanContainer
INFO: HHH10005002: No explicit CDI BeanManager reference was passed to Hibernate, but CDI is available on the Hibernate class loader
Nov 06, 2025 2:50:30 PM org.hibernate.engine.jdbc.connections.internal.DriverManagerConnectionProviderImpl configure
WARN: HHH10001002: Using built-in connection pool (not intended for production use)
Nov 06, 2025 2:50:30 PM org.hibernate.engine.transaction.jta.platform.internal.JtaPlatformInitiator initiateService
INFO: HHH000490: Using JTA platform [org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform]
Nov 06, 2025 2:50:30 PM org.hibernate.engine.jdbc.env.internal.JdbcEnvironmentInitiator logConnectionInfo
INFO: HHH10001005: Database info:
	Database JDBC URL [jdbc:h2:mem:test;DB_CLOSE_DELAY=-1]
	Database driver: H2 JDBC Driver
	Database dialect: H2Dialect
	Database version: 2.4.240
	Default catalog/schema: TEST/PUBLIC
	Autocommit mode: false
	Isolation level: READ_COMMITTED
	JDBC fetch size: 100
	Pool: DriverManagerConnectionProviderImpl
	Minimum pool size: 1
	Maximum pool size: 20

Nov 06, 2025 2:50:29 PM com.arjuna.ats.arjuna.recovery.TransactionStatusManager start
INFO: ARJUNA012170: TransactionStatusManager started on port 53622 and host 127.0.0.1 with service com.arjuna.ats.arjuna.recovery.ActionStatusService

and that probably recreates my DB.

Ironically, I moved away from doing this in arquillian because it doesn't work well with nested classes, only to hit such an issue again.

[manovotn]

I don't know if Weld is responsible for the initialization of JPA/JTA here, but after every time Weld starts, Hibernate and Arjuna start too:

Weld as such is not booting these.
You likely have some other extensions starting them?

[manovotn]

Thanks as always for the detailed explanation. My real test case hooks up with JPA (hibernate) and JTA (narayana) to be able to test with entities and transactions. I noticed that entities that are persisted in one "class level" are not present in a nested level, e.g.:

@nlisker I am no longer in front of my PC to check but your code uses @BeforeAll in the outer class - what makes you think this will be invoked for nested classes as well? I don't think that's how JUnit behaves.
If you are executing the Sub class, I would only expect JUnit to invoke the initSub() method, not the one in the outer class.

EDIT: Turns out I was wrong, running a nested test class triggers @BeforeAll in all its outer classes.
Still, we are not starting JTA in any shape or manner - and I suppose whichever extension is might have the same issue we have here with Weld and nested tests :)

[nlisker]

Weld as such is not booting these.
You likely have some other extensions starting them?

I have explicit dependencies on hibernate and narayana, but if you mean Junit extension then Weld's is the only one. I can provide a simple test case if it helps. I will check when if their initialization is triggered on injection.

[nlisker]

In your case, when JUnit tries to execute a test for A2, you don't want to start container for WeldTest or A.
This is because you don't know all the beans you want to add to the that given test deployment - for that you need to start from the nested class (A2) and scan that one (and possibly the declaring class(es)). And we try to do that.

In my example, I would expect the injected bean in the outer class to be the same one that's used in the nested class. I see that this is not the case. This will is rather confusing as in proper Java the instance in the outer class is accessible in the inner one.

[manovotn]

In my example, I would expect the injected bean in the outer class to be the same one that's used in the nested class. I see that this is not the case. This will is rather confusing as in proper Java the instance in the outer class is accessible in the inner one.

The example you posted has non-static before all, which is not allowed except for PER_CLASS lifecycle, is that the case?
Otherwise you are correct that the beans are different and it has the same cause as I said before - by the time outer class @BeforeAll gets executed, we don't even have information about the "inner" container that's going to service your test 🤷