Suppress duplicate warning log for same application logger factory class

[bhuvan-somisetty]

Fixes #14889

Problem

When running a Spring Boot app with -Dotel.javaagent.logging=application, the following warning appears spuriously at startup:

WARN - ApplicationLoggerBridge - Multiple application logger implementations were provided. \
The javaagent will use the first bridge provided and ignore the following ones (this one).

Spring Boot's LoggingApplicationListener calls initialize() more than once during startup (e.g. for ApplicationEnvironmentPreparedEvent and ApplicationStartedEvent). The javaagent instruments this method on exit, so Slf4jApplicationLoggerBridge.install() is invoked each time. On the second call the factory is already set, and the existing code unconditionally logs the warning even though the exact same factory class is being re-registered and nothing went wrong.

Fix

Replace the AtomicBoolean installed gate and a separate volatile actualFactoryClass field with a single AtomicReference<Class<? extends InternalLogger.Factory>>. The CAS is now null → incomingClass, so the winning factory class is stored atomically at the moment the gate is claimed.

Any thread that loses the CAS immediately sees a non-null value from installedFactoryClass.get(), closing the race window where a same-class re-install could still emit the warning before the previous approach had a chance to assign actualFactoryClass.

Behaviour:

• Same class re-install → return silently; bridge is already correctly set up.
• Different class → log the existing warning; this is a genuine conflict.

Changes

• ApplicationLoggerFactory.java replace AtomicBoolean + volatile field with AtomicReference<Class<...>> and CAS null → incomingClass
• ApplicationLoggerFactoryTest.java add shouldIgnoreSubsequentInstallationsOfSameClass test; update shouldOnlyInstallTheFirstBridge to use distinct FirstFactory/SecondFactory classes so the warning is still triggered for genuinely different implementations

[Copilot]

Pull request overview

This PR suppresses a spurious WARN log emitted by the javaagent's application-logger bridge. In Spring Boot apps, LoggingApplicationListener#initialize (and/or the SLF4J LoggerFactory path) can drive multiple registration calls of the same Slf4jApplicationLoggerBridge into ApplicationLoggerFactory. Previously, every install after the first logged "Multiple application logger implementations were provided…", even when the registering factory was the identical class. The change records the class of the first successfully installed factory and short-circuits subsequent installs of the same class without warning, while still warning when a genuinely different factory class is provided. This addresses issue #14889.

Changes:

• Track the installed factory's class (actualFactoryClass) and return early on repeat installs of the same class instead of logging a warning.
• Preserve the existing warning behavior when a different factory class attempts to install after the first.
• Update/add unit tests to distinguish same-class repeated installs (no warning) from different-class installs (warning), using concrete FirstFactory/SecondFactory mock targets.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
javaagent-internal-logging-application/src/main/java/io/opentelemetry/javaagent/logging/application/ApplicationLoggerFactory.java	Adds actualFactoryClass field and same-class early-return in install(...) to suppress the duplicate warning.
javaagent-internal-logging-application/src/test/java/io/opentelemetry/javaagent/logging/application/ApplicationLoggerFactoryTest.java	Updates the first-bridge test to use distinct factory classes and adds a test asserting same-class re-install logs no warning; introduces FirstFactory/SecondFactory test helpers.

[opentelemetry-pr-dashboard]

This PR has review comments. Review suggestions, whether from maintainers or automated reviewers, aren't always correct or required. Please evaluate each comment on its merits, then make sure each thread has a clear outcome.

For example, link to the commit if you applied a suggestion, explain why it wasn't applied, or ask a follow-up question.

Automation flags a PR for human review once every review thread has a reply or is marked as resolved.

Status across open PRs is visible on the pull request dashboard.