[Feature] Replace jersey in hugegraph-client/common to avoid SpringBoot/Jarkata conflicts

zhenyuT commented 11 months ago

Feature Description (功能描述)

使用hugegraph-client进行应用开发时，遇到和spring boot版本兼容问题，以及不能和fastjson一起使用的问题。

由于历史原因，JavaEE更名为JakartaEE，JakartaEE 9命名空间由javax更改为jakarta，原来为javax开头的包名都改为了jakarta开头。 hugegraph-client使用的jersey版本为3.x，使用的是jakarta开头的包名，而在spring boot2.x版本中使用的还是javax的包名，自然就导致了不兼容(项目启动报NoClassDefFoundError的错)

在https://github.com/apache/incubator-hugegraph-toolchain/issues/495中通过升级spring boot到2.7.3能解决问题，项目可以正常启动运行，但是使用的其实还是javax的包名，只是使用javax包名的类没有被加载而已，并没有从根本上解决问题，存在潜在隐患。

虽然可以通过一些手段解决问题(升级spring boot版本、去除fastjson依赖等)，但是究其根本原因，主要还是因为hugegraph-client使用jersey作为http客户端的实现。

作为使用hugegraph的应用开发者，我们会把hugegraph-client引入到我们的项目中，我们希望我们引入的类库最好轻量一点，尽量少的依赖其他类库。要知道对于一个已有旧项目来说，升级spring boot版本也不是一件容易的事。如果项目基于alibaba套件开发，也不太可能去除fastjson依赖。

尽管在社区的帮助下，我们最终还是会有办法解决这些问题。但是为什么不把罪魁祸首jersey给解决掉呢？最理想的情况是，不管使用者的项目环境是怎样的，只需要引入hugegraph-client依赖就可以直接正常使用，而不需要花费精力去解决这些烦人的依赖冲突问题。

Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

imbajin commented 11 months ago

Some difference & benchmark for HTTP-frames:

HttpUrlConnection VS Apache HttPClient 3.x VS HttpClient 4.x VS java11 http VS Jetty VS HttpAsyncClient

zhenyuT commented 7 months ago

尝试升级hugegraph-client版本到1.2.0(stage仓库)，解决了和fastjson冲突报错的问题修改配置如下：

 <dependency>
            <groupId>org.apache.hugegraph</groupId>
            <artifactId>hugegraph-client</artifactId>
            <version>1.2.0</version>
</dependency>

更新: 目前 maven 中央仓库已能直接拉取到包, 不需要再配置这个了~

 <repositories>
        <repository>
            <id>staged-releases</id>
            <url>https://repository.apache.org/content/groups/staging/</url>
        </repository>
</repositories>

apache / incubator-hugegraph-toolchain