服务容器稳定性等待超时及IllegalStateException问题排查求助

Let’s break down your problem step by step—you’re hitting a 300-second timeout waiting for the service container to stabilize, plus an IllegalStateException about stopped components, all tied to your @Startup @Singleton StartupShutdownBean that injects SysUser. Here’s how to diagnose and fix this:

1. Dig into your Startup Singleton’s initialization logic #

Your @Startup @Singleton bean is one of the first components the container tries to initialize. If it gets stuck during setup, the entire container will hang until it times out.

• Check the @PostConstruct method in StartupShutdownBean: Does it run long-running operations (like slow database calls, unresponsive remote services) without timeouts? Is there a hidden dead loop?
• Verify the SysUser bean you’re injecting: Does it have its own @PostConstruct logic that might be failing? Is it dependent on another component that hasn’t finished starting up yet? For example, if SysUser relies on a database connection pool that’s still initializing, the injection could block indefinitely.

2. Validate your beans.xml placement and configuration #

Your EJB module’s beans.xml is in resources/META-INF and WAR’s in WEB-INF—that’s correct for Java EE, but double-check these details:

• Confirm bean-discovery-mode in both beans.xml files: For Java EE 7+, the default is annotated, meaning only beans with valid scope/CDI annotations (like @Stateless, @ApplicationScoped, @Named) are picked up. If SysUser or its dependencies lack these annotations, the container won’t find them, leading to injection failures that block startup.
• Ensure the files are correctly packaged: With Maven/Gradle, make sure the EJB’s beans.xml ends up in ejb.jar/META-INF and the WAR’s in your-war.war/WEB-INF—build tool misconfigurations can sometimes put these files in the wrong place, making them invisible to the container.

3. Adjust container startup timeout (temporary workaround) #

The 300-second timeout is a default container setting, but if your initialization truly needs more time, you can tweak it:

• For WildFly, modify the startup-timeout attribute in standalone.xml under the ee subsystem, or pass a system property at startup: java -Dorg.jboss.as.ee.startup.timeout=600 ... (sets it to 10 minutes). Note: This is just a band-aid—you still need to fix the root cause of the hang.

4. Enable debug logs to uncover hidden errors #

Timeout errors often mask underlying issues that the container doesn’t surface upfront. Enable DEBUG-level logging for your container:

• Look for clues like NoSuchBeanDefinitionException (missing beans) or DependencyResolutionException (failed injections) that might occur before the timeout. These can tell you exactly where the startup process is getting stuck.
• Check logs for any database connection failures, missing resources, or unresponsive services that your StartupShutdownBean or SysUser depend on.

5. Isolate the StartupBean to confirm the issue #

Temporarily comment out the @Startup annotation on StartupShutdownBean, or remove the bean entirely, then try starting the container. If it launches successfully, you’ve confirmed the problem lies with this bean’s initialization. From there, you can add back parts of its logic one by one to pinpoint the exact stuck point.

For example, if your @PostConstruct method has code like this that’s blocking:

@PostConstruct
public void init() {
    // This call waits indefinitely for a database that's not ready
    sysUserRepository.loadDefaultAdmin();
}

You’d want to add a timeout to this operation, or ensure the database is fully initialized before the container starts.

内容的提问来源于stack exchange，提问作者Joe