autoStart="false" app fails to start if config refreshes after MBean start

[jimblye]

Describe the bug

When an application is configured with autoStart="false", if the application is started using the application MBean during server startup, and there is a concurrent update to the server configuration, the start request is lost and the application fails to start, remaining in STOPPED state without displaying a warning or error message.

Technical Details & Root Cause

1. For an application configured with autoStart="false", Liberty's ApplicationStateMachine (ASM[1]) creates an explicit-start barrier (waitingForExplicitStartFuture).
2. The external controller invokes ApplicationMBean.start(), resolving the barrier so the app can start. If prerequisite dependencies (e.g., Resource Adapters) are still starting, ASM[1] waits for them.
3. If a configuration file refresh occurs during this window, OSGi Configuration Admin delivers a configuration deletion for the old configuration ID followed by an update for the new configuration ID.
4. ApplicationConfigurator uninstalls and destroys ASM[1], discarding the in-flight start request.
5. When the new configuration arrives, ApplicationConfigurator creates a brand-new state machine (ASM[2]), which sets up a fresh explicit-start barrier.
6. Because the caller already called start() and is now only polling for STARTED state, no second start() call is ever made. ASM[2] waits forever in STOPPED state.

Steps to Reproduce

1. Configure an application with autoStart="false" in an included configuration file (e.g. installedApps.xml):

   <application id="myApp" name="myApp" type="ear" location="myApp.ear" autoStart="false"/>

2. Start Liberty under conditions where Resource Adapters or server features take a few moments to initialize.
3. As soon as the ApplicationMBean for myApp is published in STOPPED/INSTALLED state, invoke ApplicationMBean.start().
4. Trigger a configuration refresh/re-scan of installedApps.xml while the application is waiting for dependencies to start.
5. Observe that Liberty re-registers the ApplicationMBean in STOPPED state, and the application never transitions to STARTED.

Expected behavior
When an explicit start() request has already been received for an application, Liberty should retain that start intent across transient configuration updates/re-registrations for the same application name, allowing the application to complete startup once server dependencies are ready.

Diagnostic information:

• OpenLiberty Version: 26.0.0.3 (wlp-1.0.111.cl260320260314-0319) / all versions using com.ibm.ws.app.manager
• Affected feature(s): appSecurity, enterpriseBeans, jca, cics:core-1.0 (any configuration using autoStart="false")
• Java Version:

  java version "21.0.11" 2026-04-14
  IBM Semeru Runtime Certified Edition for z/OS (21.0.11+10)
  

• server.xml configuration:

  <server description="sampleServer">
      <featureManager>
          <feature>pages-3.1</feature>
          <feature>enterpriseBeansLite-4.0</feature>
          <feature>jca-2.1</feature>
      </featureManager>
  
      <include optional="true" location="installedApps.xml"/>
  </server>

Additional context

• Discovered in customer case TS022427317 on z/OS following a system IPL where high I/O causes CICS BUNDLE installation to rewrite installedApps.xml concurrently with Liberty startup.
• Trace log analysis confirms that com.ibm.ws.app.manager_0 received and resolved the explicit start future (AppDep[17]), but was uninstalled during a config refresh before startup finished. The replacement instance (com.ibm.ws.app.manager_2) created a new explicit start future (AppDep[26]) and stalled indefinitely waiting for a start() call that never arrived.