servicecomb-java-chassis
servicecomb-java-chassis copied to clipboard
apache
ServiceComb Java Chassis is a Software Development Kit (SDK) for rapid development of microservices in Java, providing service registration, service discovery, dynamic routing, and service management...
``` ZipkinTracingIntegrationTest.sendsTracingToConfiguredAddress:47->TracingTestBase.assertThatSpansReceivedByZipkin:66->TracingTestBase.tracedValues:86 » NullPointer Cannot invoke "java.util.List.stream()" because "spans" is null ```
- part1 change `org.junit.Assert` to `org.junit.jupiter.api.Assertions`
java-chassis-dependencies版本：2.6.0 文件下载流程：浏览器---》服务A接口---》服务B接口 接口响应信息： 服务B接口返回类型：FilePart 服务A接口返回类型：ReadStreamPart **问题现象： 直接使用Postman调用服务B接口下载文件与原始文件二进制一致 使用Postman调用服务A接口下载文件与原始文件不一致 通过浏览器下载文件与原始文件不一致** 参考文件下载开发指导：https://huaweicse.github.io/servicecomb-java-chassis-doc/java-chassis/zh_CN/general-development/file-download.html 1. 服务提供者是可以直接返回Part类型（FilePart、ReadStreamPart都是Part实现） `如果需要根据请求参数动态创建临时文件，下载完成后，将临时文件删除，可以采用 Part 类型的参数。 @GetMapping(path = "/file") public Part file(String content) throws IOException { File file = createTempFile(content); return...
**Describe the bug** 背景：servicecomb-java-chassis 2.1.5在使用过程中，我们的rpc调用服务端会校验客户端在请求头中携带的目标实例ID，发现某些rpc请求的实例ID对应已经老化的实例ID。 现象：服务缓存中存在已经老化的旧实例。 原因分析：RefreshableMicroserviceCache缓存会在pullInstance后更新记录的revisionId，如果在safemode期间pullInstance成功了会导致此处rev被更新的和sc中的一致，在退出安全模式后携带此rev再次pullInstance时如果此时实例在sc中未有变更会直接响应304，不会触发缓存刷新，导致在安全模式中不老化的实例无法正常下线。 解决建议：在安全模式下不更新缓存中记录的revisionId。 **To Reproduce** 复现方法：参考以下测试用例。 _RefreshableMicroserviceCacheTest.java_ ``` @Test public void refresh_exit_safe_mode_down_old_instance() { ArrayList instances = new ArrayList(); findServiceInstancesOprHolder.value = params -> { Assert.assertEquals("consumerId", params[0]);...
Hi, we're using Java-Chassis 1.3.7 and find that if some controllers are using the same `schemaId`(carried by annotation `@RestSchema`), Java-Chassis does not throw any Exception at the boot up stage....
Only the service name is used for matching. When the gray release rule is Appname combined with Servicename, the matched instance is 0.
netty nativetransport 在javachassic 是不是有助于提高性能. arm x86混合的情况下servicecomeb 有没有封装. 有没有对比的性能测试或者建议。
背景: TLS证书可能过期, 我们已有机制可以自动在服务器上更新 TLS 证书, 但 Java-Chassis 框架当前需要重启进程才能加载新的 TLS 证书(REST over Vert.x传输模式) 能否支持 TLS 证书热更新, 让业务进程能够在不重启进程的情况下平滑替换使用新的 TLS 证书?
现在代码都是把异常捕获了之后 放到返回体里面的 如果抛出去一个异常 前台会报cse internal error这种错误 cse这边对外有没有提供一个接口或者啥 能够处理业务层抛出去的异常的
通过hibernate-validator的注解抛出的参数校验异常，看源码会使用默认语言进行国际化，这个默认语言没追溯到时如何初始化的，这块是否可以扩展，自定义业务的语言选择，例如根据用户注册地区进行选择语言，或者根据请求头Accept-Language选择语言等等。
