Apache Dubbo Spring Boot Project: A Starter That Has Moved On

The problem dubbo-spring-boot-starter solves for Dubbo users

Dubbo is a Java RPC framework. On its own, a Dubbo application is configured through XML files or a programmatic API: you declare the application name, the protocol, the registry address, and every service you export or reference. Spring Boot applications expect the opposite convention, where a classpath dependency plus a few properties is enough to start a working context. This project exists to close that gap. It packages the Dubbo configuration surface as a Spring Boot starter, so a service provider is a class annotated with @DubboService and a consumer is a field annotated with @DubboReference. The intended audience is Java teams that already run Spring Boot and want Dubbo's interface-based remote calls, load balancing, and service registration without maintaining a parallel XML configuration tree. The repository is split into modules that map to that goal: dubbo-spring-boot-autoconfigure for the annotation-driven wiring, dubbo-spring-boot-actuator for production features such as health checks, dubbo-spring-boot-starter as the dependency you actually add, and dubbo-spring-boot-samples for runnable examples. There is also dubbo-spring-boot-compatible, which exists to serve older Dubbo lines.

How the autoconfiguration and actuator modules fit together

The mechanism is standard Spring Boot autoconfiguration. Adding dubbo-spring-boot-starter puts the autoconfigure module on the classpath, and Spring Boot's autoconfiguration machinery reads Dubbo settings from the environment. The README shows the convention clearly: dubbo.application.name defaults to ${spring.application.name}, so an application that already sets spring.application.name does not need to repeat itself. The scan path for annotated Dubbo components is set through dubbo.scan.base-packages, and the protocol and registry are plain properties (dubbo.protocol.name, dubbo.protocol.port, dubbo.registry.address). The actuator module is separate and optional. It supplies production-facing endpoints, which the README describes as security, health checks, and externalized configuration. That separation matters: if you only want the RPC wiring, you take the starter; if you also want Dubbo state exposed to Spring Boot's management layer, you add the actuator module. The samples module is where the two usage scenarios live, a provider and a consumer, and it is the fastest way to see the intended shape of a project before writing your own.

Installing the starter and making a first provider call

The README gives the dependency block directly. You import the Spring Boot dependencies BOM and the Dubbo dependencies BOM in dependencyManagement, then declare the starter. The versions below are the ones the README pairs together, Spring Boot 2.3.0.RELEASE and Dubbo 2.7.8, and the starter artifact is pinned to 2.7.8 as well.

<properties>
    <spring-boot.version>2.3.0.RELEASE</spring-boot.version>
    <dubbo.version>2.7.8</dubbo.version>
</properties>

<dependencies>
    <dependency>
        <groupId>org.apache.dubbo</groupId>
        <artifactId>dubbo-spring-boot-starter</artifactId>
        <version>2.7.8</version>
    </dependency>
</dependencies>

If the artifact does not resolve, the README says to add the Apache development snapshot repository, noting that it has releases disabled and snapshots enabled.

<repositories>
    <repository>
        <id>apache.snapshots.https</id>
        <name>Apache Development Snapshot Repository</name>
        <url>https://repository.apache.org/content/repositories/snapshots</url>
        <releases>
            <enabled>false</enabled>
        </releases>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
</repositories>

The README's first real use is a provider. Define an interface, implement it, annotate the implementation, and supply a bootstrap class. The service name in the response comes from the dubbo.application.name property, which falls back to spring.application.name.

@DubboService(version = "1.0.0")
public class DefaultDemoService implements DemoService {

    @Value("${dubbo.application.name}")
    private String serviceName;

    public String sayHello(String name) {
        return String.format("[%s] : Hello, %s", serviceName, name);
    }
}

The provider's application.properties sets the scan package, the protocol, and a registry address. The README uses N/A for the registry in this sample, which means no registry is involved and the consumer connects by direct URL.

spring.application.name=dubbo-auto-configuration-provider-demo
dubbo.scan.base-packages=org.apache.dubbo.spring.boot.sample.provider.service
dubbo.protocol.name=dubbo
dubbo.protocol.port=12345
dubbo.registry.address=N/A

On the consumer side, the README annotates the field with @DubboReference, pinning the version and pointing at the provider's address directly. The bootstrap class runs the Spring context, calls sayHello through an ApplicationRunner, and closes. The README warns that the provider must already be running for this to work.

@DubboReference(version = "1.0.0", url = "dubbo://127.0.0.1:12345")
private DemoService demoService;

The consumer's application.yml only needs the Spring application name, because the Dubbo application name inherits it.

The archived-README problem and the version trap

The README's first line after the title states that the repository has been archived and that all implementations moved to apache/dubbo. The repository metadata says it is not archived and the last push was on 2026-05-15, so the two signals disagree, and a reader who only looks at the GitHub header will get the wrong impression. Treat the README as the project's own statement about where the code lives. The practical consequence is that bug reports, fixes, and new features belong in apache/dubbo, not here. The second limitation is version coupling. The README's released-version section pairs Spring Boot 2.3.0.RELEASE with Dubbo 2.7.8, and the most recent release listed for this repository is 2.7.9 from 2021-03-12. Nothing in the README describes a Spring Boot 3 line, and nothing describes Jakarta namespace migration. If your application is on a newer Spring Boot generation, this starter is the wrong tool, and the migration path is to the Dubbo project itself. There is also a legacy table in the README for Dubbo versions below 2.7.0, which points at the 0.2.x and 0.1.x branches of this repository and pairs them with Spring Boot 2.x and 1.x respectively. Those branches are the answer for old Dubbo codebases, not the current starter.

What you give up compared with the Dubbo repository itself

The real alternative is taking Dubbo directly from apache/dubbo rather than through this starter repository. The difference is one of ownership and packaging, not of protocol. This repository is a thin Spring Boot integration layer: autoconfiguration, actuator endpoints, a starter POM, samples, and a compatible module. Dubbo itself is the RPC implementation, the registry integrations, the protocol implementations, and the release train that continues. If you depend on dubbo-spring-boot-starter 2.7.8, your RPC behavior is Dubbo's behavior; what you get from this repository is the property binding and the annotation scanning. That means a fix to a protocol bug will land in apache/dubbo and reach you through a Dubbo version bump, not through a change here. Teams that need current Dubbo features should plan to consume the Spring Boot integration from the Dubbo project and treat this starter as a pinned, frozen artifact. The counter-argument is real: a frozen artifact is predictable, and if your service is stable on Spring Boot 2.3.x, the lack of churn is not a defect.

Maintenance, licence, and what an upgrade actually costs

The last push to this repository was on 2026-05-15, and the newest release listed is 2.7.9 from 2021-03-12. Those two facts point in different directions, and the README resolves the tension by saying the implementations moved to apache/dubbo. Plan your upgrade budget around Dubbo releases, not around this repository's commit activity. Upgrading means moving the dubbo.version property and the starter version together, then re-running the provider and consumer samples, because the README's configuration keys (dubbo.scan.base-packages, dubbo.protocol.name, dubbo.protocol.port, dubbo.registry.address) are the surface most likely to shift between Dubbo lines. The licence is Apache-2.0, which is a permissive licence that permits commercial use and modification, and the repository carries a NOTICE file alongside LICENSE. That is a description of the licence, not legal advice; if you redistribute a modified build, read the NOTICE and LICENSE files in the repository and follow your own legal review process. One build detail worth knowing: the repository ships mvnw and mvnw.cmd, so the README's instruction to run mvn install can be run through the wrapper if your environment does not have a matching Maven installation.

Editorial conclusion

Adopt dubbo-spring-boot-starter if you are on Spring Boot 2.3.x with Dubbo 2.7.x and want annotation-driven RPC without hand-writing XML configuration. Do not adopt it for a new Spring Boot 3 project, and do not treat this repository as the place to file issues, because the README states the implementations moved to apache/dubbo. Before committing, verify two things in your own build: that your Spring Boot version matches the 2.3.0.RELEASE line the README pairs with Dubbo 2.7.8, and that the starter's autoconfiguration still applies under whatever dependency management your team uses, since the last release on this repository was 2.7.9 on 2021-03-12.

Frequently asked questions

Official sources

1. apache/dubbo-spring-boot-project on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases