Updates ElasticJob to 3.0.4 to block CVEs for SnakeYAML delivery

[linghengqian]

Fixes #24636.

Changes proposed in this pull request:

• Updates ElasticJob to 3.0.4 to block CVEs for SnakeYAML delivery. Refer to https://github.com/apache/shardingsphere-elasticjob/releases/tag/3.0.4 .
• Also fixes Snakeyml 2.1 compatibility issue with shardingsphere-jdbc-core-spring-boot-starter 5.2.1 #28233.
• Also fixes Please support snakeyaml 2.0. #28067.
• Also fixes The service starts the error when upgrade snakeyaml to version 2.0 #27370.
• Also fixes Sharding startup failed after upgrading the snake yml component to version 2.0 #25291.
• Since the CI of the Exmaple module is broken on JDK21, I am not handling the changes to the Example module in this PR. Refer to https://github.com/apache/shardingsphere/actions/runs/6563502380 .

---

Before committing this PR, I'm sure that I have checked the following options:

• My code follows the code of conduct of this project.
• I have self-reviewed the commit code.
• I have (or in comment I request) added corresponding labels for the pull request.
• I have passed maven check locally : ./mvnw clean install -B -T1C -Dmaven.javadoc.skip -Dmaven.jacoco.skip -e.
• I have made corresponding changes to the documentation.
• I have added corresponding unit tests for my changes.

[xiohuchi]

不知道修复版本什么时候发布，有大佬知道怎么临时解决吗

[linghengqian]

不知道修复版本什么时候发布，有大佬知道怎么临时解决吗

@xiohuchi

• You can manually compile the project by following the steps below, and upload the corresponding products in the local Maven repository to your private repository. This uses SDKMAN!.

sdk install java 21.0.2-graalce
sdk use java 21.0.2-graalce

git clone [email protected]:apache/shardingsphere.git
cd ./shardingsphere/

./mvnw clean install -Prelease -T1C -DskipTests -Djacoco.skip=true -Dcheckstyle.skip=true -Drat.skip=true -Dmaven.javadoc.skip=true -B

• I'm not the PMC for the project, so I can't make any subjective assumptions about when the next release will be. If you need a release sooner, you should start a discussion thread on the mailing list.

[1Yangc]

   <dependency>
        <groupId>org.apache.shardingsphere</groupId>
        <artifactId>shardingsphere-jdbc</artifactId>
        <version>5.4.2-SNAPSHOT</version>
    </dependency>

Pay attention. Use shardingsphere-jdbc replace shardingsphere-jdbc-core

It's worked!
it bothered me for two days.
Thanks!

and how long can we use in new 5.4.2 release version?

[linghengqian]

Pay attention. Use shardingsphere-jdbc replace shardingsphere-jdbc-core

• This is the change brought by Merge shardingsphere-jdbc-core to shardingsphere-jdbc module and update doc #30182 .

and how long can we use in new 5.4.2 release version?

• If you expect a faster release, you should leave a message in the mail thread at https://lists.apache.org/thread/0kwvkzclnhn312vjlcyyr02md995yfv9 . It seems that the several delays to the 5.5.0 milestone are due to the need to adjust the metadata structure.
• As a committer, I personally only have non-binding release voting right. In any case, according to ASF regulations, the release process must be completed on the mailing list, which has nothing to do with github.com.

[1Yangc]

Pay attention. Use shardingsphere-jdbc replace shardingsphere-jdbc-core

• This is the change brought by Merge shardingsphere-jdbc-core to shardingsphere-jdbc module and update doc #30182 .

and how long can we use in new 5.4.2 release version?

• If you expect a faster release, you should leave a message in the mail thread at https://lists.apache.org/thread/0kwvkzclnhn312vjlcyyr02md995yfv9 . It seems that the several delays to the 5.5.0 milestone are due to the need to adjust the metadata structure.
• As a committer, I personally only have non-binding release voting right. In any case, according to ASF regulations, the release process must be completed on the mailing list, which has nothing to do with github.com.

Thanks!

[lizhongyue248]

   <dependency>
        <groupId>org.apache.shardingsphere</groupId>
        <artifactId>shardingsphere-jdbc</artifactId>
        <version>5.4.2-SNAPSHOT</version>
    </dependency>

Pay attention. Use shardingsphere-jdbc replace shardingsphere-jdbc-core

It's worked! it bothered me for two days. Thanks!

and how long can we use in new 5.4.2 release version?

Hello, did you manually compile the version 5.4.2-SNAPSHOT?

[linghengqian]

• @lizhongyue248 Refer to 5.4.1 yaml Dependency #30318 (comment) .

[daipeizhe]

I found that even with ShardingSphere 5.4.1 and SnakeYaml 2.1, the startup was successful. Why?

[linghengqian]

I found that even with ShardingSphere 5.4.1 and SnakeYaml 2.1, the startup was successful. Why?

• There are many possible reasons. For example, you did not call the conflicting method of SnakeYAML. This may be because you only created the ShardingSphere data source through DistSQL of ShardingSphere Proxy or the Java API of ShardingSphere JDBC.

[daipeizhe]

I found that even with ShardingSphere 5.4.1 and SnakeYaml 2.1, the startup was successful. Why?

• There are many possible reasons. For example, you did not call the conflicting method of SnakeYAML. This may be because you only created the ShardingSphere data source through DistSQL of ShardingSphere Proxy or the Java API of ShardingSphere JDBC.

If I manually reference SnakeYaml in the pom.xml file and specify a version above 2.x, the startup is fine; However, if you do not manually reference SnakeYaml, the SnakeYaml version of the project, although it is also 2.0, will still start error. In addition, I did configure ShardingSphere JDBC through the Java API.

[linghengqian]

I found that even with ShardingSphere 5.4.1 and SnakeYaml 2.1, the startup was successful. Why?

• There are many possible reasons. For example, you did not call the conflicting method of SnakeYAML. This may be because you only created the ShardingSphere data source through DistSQL of ShardingSphere Proxy or the Java API of ShardingSphere JDBC.

If I manually reference SnakeYaml in the pom.xml file and specify a version above 2.x, the startup is fine; However, if you do not manually reference SnakeYaml, the SnakeYaml version of the project, although it is also 2.0, will still start error. In addition, I did configure ShardingSphere JDBC through the Java API.

• This doesn't really mean anything, as ShardingSphere JDBC 5.4.1 explicitly uses methods that were removed from SnakeYAML 2.0.

[daipeizhe]

I found that even with ShardingSphere 5.4.1 and SnakeYaml 2.1, the startup was successful. Why?

• There are many possible reasons. For example, you did not call the conflicting method of SnakeYAML. This may be because you only created the ShardingSphere data source through DistSQL of ShardingSphere Proxy or the Java API of ShardingSphere JDBC.

If I manually reference SnakeYaml in the pom.xml file and specify a version above 2.x, the startup is fine; However, if you do not manually reference SnakeYaml, the SnakeYaml version of the project, although it is also 2.0, will still start error. In addition, I did configure ShardingSphere JDBC through the Java API.

• This doesn't really mean anything, as ShardingSphere JDBC 5.4.1 explicitly uses methods that were removed from SnakeYAML 2.0.

You're right, I found out that the framework I was using overwrote the missing parameterless Representer class constructor.

[linghengqian]

• I've opened https://bitbucket.org/snakeyaml/snakeyaml/issues/1093/yaml-constructor-does-not-respect for follow-up effects of this PR.