Removing Spring configuration from ShardingSphere

[RaigorJiang]

Hi community

I want to discuss removing Spring Boot Starter and Spring Namespace configuration from ShardingSphere.

Background

Currently, ShardingSphere-JDBC supports Java API, YAML, Spring Boot Starter and Spring Namespace configuration ways, and there are the following problems:

1. When the API changes, it is necessary to adjust various configuration files, and the workload is heavy;
2. The community needs to maintain various configuration documents;
3. Spring bean life cycle management is easily affected by other dependencies of the project, such as PostProcessor cannot be executed normally [1];
4. Spring Boot Starter and Spring NameSpace are influenced by Spring, and the configuration style is quite different from YAML;
5. Spring Boot Starter and Spring NameSpace are affected by the Spring version, and there will be configuration compatibility issues. For example, Spring Boot recently released version 3.0, and the previous registration file spring.factories will become invalid [2].

Aim

Starting from 5.1.2, ShardingSphere provides a new configuration method: ShardingSphere Driver[3], which can help us achieve consistency in configuration ways, for example:

• Spring Boot

spring:
  datasource:
    driverClassName: org.apache.shardingsphere.driver.ShardingSphereDriver
    url: jdbc:shardingsphere:${path}/config.yml

-Spring Namespace

<bean id="shardingDataSource" class="org.springframework.jdbc.datasource.SimpleDriverDataSource">
    <property name="driverClass" value="org.apache.shardingsphere.driver.ShardingSphereDriver" />
    <property name="url" value="jdbc:shardingsphere:${path}/config.yaml" />
</bean>

Through the above ways, users can use unified YAML to configure ShardingSphere in their Spring Boot or Spring Namespace projects, which will help the community better focus on features rather than configuration compatibility.

Therefore, I suggest removing Spring configuration-related modules from ShardingSphere, including shardingsphere-jdbc-spring and spring modules under each feature.

Of course, this will also have some implications:

1. Removing the spring module will remove AlgorithmProvided related classes at the same time. If users use Spring Bean to manage custom algorithms, some adjustments are required;
2. The transaction annotation scanning for Spring will also be removed (TransactionTypeScanner). If users need to change the transaction type at the method level, they can use the Java API. We may consider providing SQL Hint in the future, refer to Hint Routing [4].

After the Spring configuration is removed, the configuration consistency of ShardingSphere-JDBC and ShardingSphere-Proxy will be better, and I hope the community can agree to this proposal.

If there are no objections, I hope to have this done before the next release.

I am very grateful to the contributors and users of the community. It is the participation of each of you that makes this project better and better.

[1] #18093
[2] https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-3.0-Migration-Guide
[3] https://shardingsphere.apache.org/document/5.1.2/en/user-manual/shardingsphere-jdbc/jdbc-driver/
[4] https://shardingsphere.apache.org/document/5.1.2/en/user-manual/shardingsphere-jdbc/special-api/sharding/hint/

Tasks

• Update examples to use ShardingSphere-Driver
• Update Spring Boot and Spring Namespace documents
• Remove spring configration from global rules
• Remove spring configration from each feature
• Remove module shardingsphere-jdbc-spring
• Remove AlgorithmProvided related classes
• Remove AlgorithmProvided related documents

[linghengqian]

• Great, this definitely closes ShardingSphere Bean is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying) #11650 which requires refactoring of shardingsphere's springboot starter. It can also solve the three warnings used under SpringBoot 3.0.0.

[RaigorJiang]

Completed. Thank you all!