Resolving Eclipse Equinox Boot-Delegation and NoClassDefFoundError Exceptions in Java Agent 26.1 and Below When instrumenting enterprise applications that embed the Eclipse Equinox OSGi framework, runtime initialization errors can halt deployment. Understanding how the underlying framework processes JVM bootstrap properties is critical to restoring agent visibility. Technical Symptoms: Java Agent Initialization Failure Exception The following exception occurs during Java Agent initialization when the customer attempted to instrument their application ( Informatica 10.5.8 – latest version of Informatica at the time) with Java Agent version <= 26.1 (latest version of Java Agent at the time) NoClassDefFoundError: com/singularity/ee/agent/appagent/entrypoint/bciengine/FastMethodInterceptorDelegatorBoot Root Cause Diagnosis: Equinox OSGi Framework and System Property Siloing The root cause is due to the com.singularity.* package not being boot-delegated within the Eclipse Equinox OSGi framework used by Informatica 10.5.8. The JVM arguments do include: -Dorg.osgi.framework.bootdelegation=com.singularity.* which was added as a system property, and the FastMethodInterceptorDelegatorBoot class is present on the boot classpath (confirmed by the agent starting successfully). However, the Equinox framework is not reading this value from system properties. Eclipse Equinox, like Apache Felix, can be initialized programmatically by passing a configuration Map to its constructor: new org.eclipse.osgi.launch.Equinox(Map<String, String> configuration) When launched this way, the framework reads its properties (including org.osgi.framework.bootdelegation) exclusively from the provided configuration map. System properties set via -D flags are not automatically included unless the embedding application explicitly copies them into the map. A similar challenge had already been addressed for Apache Felix. Internal Engineering Context The Java Agent code includes ApacheFelixOSGiInterceptor that intercepts org.apache.felix.framework.Felix.<init>(Map) and injects com.singularity.* into the org.osgi.framework.bootdelegation entry of the configuration map : https://bitbucket.corp.appdynamics.com/projects/JAVA/repos/agent-java/browse/java_agent/agent/java/appagent/core/src/main/java/com/singularity/ee/agent/appagent/services/transactionmonitor/felix/ApacheFelixOSGiInterceptor.java#43-55 However, no equivalent interceptor exists for Eclipse Equinox. Informatica 10.5.8 embeds Equinox and initializes it programmatically with its own configuration. At no point does the Informatica startup code read the org.osgi.framework.bootdelegation system property into the Equinox configuration map. The customer has no external configuration mechanism to influence this — the map contents are controlled entirely by Informatica's internal code. Resolution Roadmap: Workaround Configuration and Permanent Fixes Tactical Workaround: Implementing Custom Interceptors The issue is resolved by intercepting the Equinox constructor the same way the agent already intercepts the Felix constructor.  Placing custom-interceptors.xml at <AGENT_HOME>/ver<version>/conf/ reuses the existing ApacheFelixOSGiInterceptor logic against the Equinox entry point. This works because both Felix and Equinox follow the OSGi specification (org.osgi.framework.launch.Framework), where framework launch properties are passed as a Map<String, String> in the constructor. The ApacheFelixOSGiInterceptor reads the first parameter of the intercepted constructor (the configuration map), and adds com.singularity.* to the org.osgi.framework.bootdelegation entry. Since the Equinox constructor follows the same signature and contract, the interceptor works identically for both frameworks. Release Update Notes A permanent fix has been addressed in JavaAgent-26.4.0 ... View more

To resolve the issue of updating the access key for a running cluster agent in the AppDynamics environment, the following technical steps are recommended. Step-by-step guide Secret Management The existing Kubernetes secret named 'cluster-agent-secret' is deleted using the command: kubectl -n appdynamics delete secret cluster-agent-secret A new secret 'cluster-agent-secret' is created with the updated access key using the command: kubectl -n appdynamics create secret generic cluster-agent-secret --from-literal=controller-key=<access-key> Pod Management The running cluster agent pod is deleted using: kubectl delete po <cluster-agent-pod> -n appdynamics The deletion of the pod leads to the automatic recreation of a new cluster agent pod, which utilizes the newly created secret   Recommendations and Clarifications There is no need for reinstallation of the cluster agent or any additional configurations such as recreating the AppDynamics pod cluster agent yml, operator yml, or infraviz yml. The system automatically handles the recreation of the pod, ensuring that the changes are applied ... View more

During auto-instrumentation with the Cluster Agent, application pods may experience extended delays before reaching the Ready State. The following outlines some troubleshooting steps to help resolve this issue.  Analyze the Application Logs when Instrumentation is applied:  Pay particular attention to entries at the time of start up. These entries will consist of the Java Agent startup process printout. Determine the duration it takes for the application + java agent together are fully started. This will determine if indeed the Java Agent is contributing to the delay in Pod Readiness Analyze the Application Logs without Instrumentation:  Determine the duration it takes for the application to get fully started. This will determine if indeed the Java Agent is contributing to the delay in Pod Readiness. Presence of Health Probes defined in the Deployment:  Even as the application is fully started up, it is independent on the pod readiness state and this is influenced by Health Probes. Confirm if Health probes are defined. Have a look at the configured health probes and observe the following: If there is a lengthy duration at which the probes are configured to execute periodically (periodSeconds). This could potentially increase the time the Pod takes to attain the Ready state. Analyze the Kubernetes events for the concerned namespace (kubectl get events -n<namespace>). From the Kubernetes event messages, it can be determined if there are failing Health Probes. Recommendation: Convince/persuade the Customer to temporarily disable/remove the health probes. This will allow you quickly isolate if indeed Health Probes are responsible for the situation. Observe the time the Pod takes to attain the Ready state without the Health Probes Adjust the Health Probe configuration settings (periodSeconds, initialDelaySeconds) and observe the time the Pod takes to attain the Ready state ... View more