[BUG] azure-core native-image metadata initializes SLF4J fallback provider with Spring Boot 4.1 / GraalVM 25

[JFCote]

Bug description

Building a Spring Boot application as a GraalVM Native Image fails when azure-core is on the runtime classpath. The failure reproduces after removing Azure Monitor/OpenTelemetry entirely; the application still uses Azure Blob Storage, Azure Identity, and Azure Communication Email.

azure-core's META-INF/native-image/com.azure/azure-core/native-image.properties forces org.slf4j.LoggerFactory and com.azure.core.util.logging.ClientLogger to initialize at build time. During native-image analysis, a static initializer such as com.azure.core.util.ExpandableStringEnum.<clinit> creates a ClientLogger. SLF4J then has SubstituteServiceProvider and NOP_FallbackServiceProvider objects in the image heap, but those types are configured for runtime initialization.

Versions

• Spring Boot: 4.1.0
• Java: 25
• GraalVM Native Image:
  • Oracle GraalVM 25.0.3+9.1 in GitHub Actions
  • GraalVM Community 25.0.2+10.1 locally (same failure)
• azure-core: 1.58.1
• Azure SDKs on the classpath:
  • azure-storage-blob 12.35.0
  • azure-identity 1.18.4
  • azure-communication-email 1.1.4

Reproduction

1. Create a Spring Boot 4.1 application with the Azure SDK dependencies above.
2. Apply org.graalvm.buildtools.native.
3. Run ./gradlew nativeCompile with GraalVM 25.

The failure is reproducible both locally in a Linux Docker build and in GitHub Actions.

Actual result

Native image analysis fails:

Fatal error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException:
An object of type 'org.slf4j.helpers.SubstituteServiceProvider' was found in the image heap.
This type, however, is marked for initialization at image run time.

Object was reached by
  org.slf4j.LoggerFactory.getProvider(...)
  org.slf4j.LoggerFactory.getLogger(...)
  com.azure.core.util.logging.ClientLogger.getLogger(...)
  com.azure.core.util.logging.ClientLogger.<init>(...)
  com.azure.core.util.ExpandableStringEnum.<clinit>(...)

The same build also reports org.slf4j.helpers.NOP_FallbackServiceProvider.

Expected result

azure-core should support native-image builds with current Spring Boot / SLF4J 2 / GraalVM 25, or its native-image metadata should avoid forcing SLF4J initialization in a way that creates a fallback provider in the image heap.

Notes

• Explicitly setting --initialize-at-run-time=org.slf4j.LoggerFactory conflicts with the build-time rule from azure-core's native-image.properties.
• Forcing the fallback providers to build time may allow the build to progress, but appears unsafe because it can freeze SLF4J's NOP fallback into the executable.
• We would appreciate recommended GraalVM arguments or an updated native-image metadata configuration.

[github-actions]

Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

//cc: @alzimmermsft @samvaity

[github-actions]

🎯 Agentic Issue Triage

Summary: GraalVM native-image compilation fails when azure-core is on the classpath because its native-image.properties forces build-time initialization of ClientLogger/LoggerFactory, causing an SLF4J fallback provider (SubstituteServiceProvider) to land in the image heap while those types are marked for runtime initialization.

📋 Issue Details

Package: com.azure:azure-core:1.58.1
Affected API: com.azure.core.util.logging.ClientLogger, com.azure.core.util.ExpandableStringEnum, META-INF/native-image/com.azure/azure-core/native-image.properties
Scenarios:

• Spring Boot 4.1 app with azure-storage-blob, azure-identity, azure-communication-email compiled via org.graalvm.buildtools.native with GraalVM 25 (Oracle & Community editions)
• Native image analysis fails with UnsupportedFeatureException referencing org.slf4j.helpers.SubstituteServiceProvider and NOP_FallbackServiceProvider in the image heap

Root ask: Update azure-core's native-image metadata so it no longer forces SLF4J initialization at build time in a way that freezes a fallback provider into the native executable, or provide recommended GraalVM arguments/configuration.

🔎 Debugging / Reproduction Notes

The root cause chain: native-image.properties forces build-time initialization → ExpandableStringEnum.<clinit> creates a ClientLogger → SLF4J's LoggerFactory.getLogger() runs before any SLF4J binding is present → SubstituteServiceProvider/NOP_FallbackServiceProvider objects are placed in the heap → conflict with runtime-init configuration.

Suggested investigation steps:

1. Review META-INF/native-image/com.azure/azure-core/native-image.properties and the --initialize-at-build-time directives targeting SLF4J and ClientLogger.
2. Evaluate deferring ClientLogger construction in ExpandableStringEnum static initializer (e.g., lazy initialization) so the logger is not created during build-time class init.
3. Check whether SLF4J 2.x SubstituteServiceProvider and NOP_FallbackServiceProvider need explicit --initialize-at-run-time entries in azure-core's metadata to complement the build-time directives.
4. Test with GraalVM 25 + Spring Boot 4.1 native build to confirm the fix.

🏷️ Label Confidence

• Category: Client — issue is about SDK client library behavior and its native-image metadata; fully within SDK code control, not a REST API/service issue
• Service: Azure.Core — directly names com.azure:azure-core as the problematic artifact
• Confidence: High — artifact is explicitly stated, category is unambiguous, prediction aligns with similar Core library issues in the repository

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Azure.Core (line 56) — matched on service label "Azure.Core"
• AzureSdkOwners: @alzimmermsft, @samvaity
• ServiceOwners: none listed
• Routing action: Assigned @alzimmermsft (random pick from two AzureSdkOwners); added needs-team-attention; @mentioned both AzureSdkOwners in routing comment
• Scan notes: Scanned bottom-to-top; no more-specific multi-label entry for %Azure.Core was found before reaching line 56

Generated by Agentic Triage for #49844 · 29.5 AIC · ⌖ 6.67 AIC · ⊞ 11K · ◷