Understanding the Dual-Mode Configuration Lifecycle in DDSBridge
In the current architecture of the DDSBridge, we are observing a "Race Condition" between legacy XML initialization and modern Spring bean injection. This results in two distinct behaviors—Case 1 (Legacy-Driven) and Case 2 (Spring-Driven)—which dictate whether we must rely on our ByteBuddy agent to correct the cache location or if the application handles it automatically.
Case 1: The Legacy-Driven Fallback (e.g., nam_router_inst1)
In this scenario, the application starts up without a pre-defined configuration bean. When the LifeCycleManager triggers the initialization of DDSQuantumService, the internal initClientConfig() method runs and finds that this.clientConfig is null.
Because no Spring bean was provided to "prime" the service, the code falls back to the legacy ClientConfigManager.getInstance().getClientConfig() call. This specifically pulls the default values embedded within the configService.xml found inside the project JAR. In these instances, the fileCacheLocation is often hardcoded to a non-existent or restricted directory (like C:/temp/...). Since this happens entirely within the internal Quantum framework logic, we must use our ByteBuddy Agent to intercept this call and manually overwrite the cache path to a valid temporary directory.
Execution Path for Case 1:
Server.main() -> LifeCycleManager.startLifecycle() -> DDSQuantumService.initClientConfig() -> (Result: Null check fails, loads from configService.xml)
Case 2: The Spring-Injected Overwrite (e.g., cache_riobridge / COES)
In more modern configurations like COES or cache_riobridge, the setup is inverted. Before the service ever reaches its initialization phase, the Spring Framework takes control. It identifies a DDSClientConfig bean defined in the spring-qas.xml which correctly references ${dds.tmpdir}.
Spring uses reflection (as seen in the setDDSClientConfig stack trace) to inject this bean directly into the service. By the time initClientConfig() is eventually called, the clientConfig variable is already populated with the correct, dynamic path. The code path then takes the "else" branch, logging "ClientConfig created using spring-qas.xml," and simply registers that existing config. In this case, the legacy XML is effectively ignored, and the system self-corrects without needing the ByteBuddy agent to step in for the cache path specifically.
Execution Path for Case 2:
Server.main() -> Spring AbstractBeanFactory.getBean() -> DDSQuantumService.setDDSClientConfig() -> (Result: Config is "pre-loaded" before init runs)
Summary for Development/Support
The "Mode" is determined entirely by the presence of a DDSClientConfig bean in the Spring context. If you are troubleshooting an instance where the cache path is stuck on an old default, you are likely in Case 1 and should verify the ByteBuddy agent's logs. If you are in Case 2, any path issues are likely due to the ${dds.tmpdir} environment variable not being set correctly in the startup script or the Spring XML itself.
Would you like me to help you refine the ByteBuddy Agent code to specifically target that "Case 1" fallback branch?
Top comments (0)