Understanding the Delegation Pattern through SLF4J, JDBC, and Dubbo

Packaging a generic solution into a mature toolkit is a common challenge for backend engineers; this article starts from popular Java logging libraries to illustrate the delegation pattern, emphasizing decentralised collaboration and the combination of a core chain with open development interfaces.

SLF4J (Simple Logging Facade for Java) acts as a façade that defines org.slf4j.Logger and org.slf4j.LoggerFactory as the standard logging API while leaving the actual implementation to third‑party adapters such as Log4j. When only slf4j-api is on the classpath, a no‑op logger ( NOPLogger ) is used.

The concrete adapters are discovered at runtime via Java’s SPI mechanism. For example, the slf4j-log4j module declares the following Maven dependencies:

<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-api</artifactId>
</dependency>

<dependency>
  <groupId>log4j</groupId>
  <artifactId>log4j</artifactId>
</dependency>

At runtime, slf4j-log4j registers its implementation through java.util.ServiceLoader , allowing the JVM to bind the Logger calls to Log4j’s concrete classes.

The delegation pattern itself consists of two essential elements: a core chain that defines the fixed processing steps, and an open interface that lets external modules plug in custom behaviour. It is useful when a standardised workflow must be shared across many teams while still permitting localized customisation.

**Example 1 – JDBC**: The JDBC API provides a uniform way to access databases. The typical workflow includes loading the driver, registering it, opening a connection, creating statements, executing queries, handling ResultSet , and finally closing resources. Driver registration can be performed either explicitly:

try {
    DriverManager.registerDriver(new Driver());
} catch (SQLException e) {
    throw new RuntimeException("Can't register driver!");
}

or implicitly via the SPI configuration file META-INF/services/java.sql.Driver , which the JVM reads at startup.

**Example 2 – Apache Dubbo**: Dubbo’s RPC framework heavily relies on its own SPI system. Interfaces such as Filter are annotated with @SPI , and implementations like ProviderAuthFilter are activated with @Activate . The filter’s core logic delegates authentication to an Authenticator obtained through ExtensionLoader :

@Activate(group = CommonConstants.PROVIDER, order = -10000)
public class ProviderAuthFilter implements Filter {
    @Override
    public Result invoke(Invoker
invoker, Invocation invocation) throws RpcException {
        URL url = invoker.getUrl();
        boolean shouldAuth = url.getParameter(Constants.SERVICE_AUTH, false);
        if (shouldAuth) {
            Authenticator authenticator = ExtensionLoader.getExtensionLoader(Authenticator.class)
                .getExtension(url.getParameter(Constants.AUTHENTICATOR, Constants.DEFAULT_AUTHENTICATOR));
            try {
                authenticator.authenticate(invocation, url);
            } catch (Exception e) {
                return AsyncRpcResult.newDefaultAsyncResult(e, invocation);
            }
        }
        return invoker.invoke(invocation);
    }
}

**Example 3 – LOG4J**: LOG4J itself adopts a reverse‑delegation approach. When both log4j-over-slf4j and slf4j-log4j are present, they can create a circular delegation that leads to a StackOverflowError , illustrating the risk of uncontrolled third‑party implementations.

In summary, the delegation pattern is appropriate when a standardised process must be governed by a central team yet still allow consumers to customise specific parts; the key is to clearly define the core chain and expose stable, well‑documented interfaces for extensions.