JuShaTa icon indicating copy to clipboard operation
JuShaTa copied to clipboard

JuShaTa是一个Java容器,提供模块隔离及模块热加载能力。

Results 6 JuShaTa issues
Sort by recently updated
recently updated
newest added

READEME中阐述了两个很主要的问题: > 容器内部署多个模块时,将会带来以下问题: > - jar包冲突:如A模块依赖于fastjson-1.1.x,B模块依赖于fastjson-1.2.x,运行时很容易会报NoSuchMethodException。 > - bean冲突:A模块和B模块都定义了xxxService,则会报bean冲突(当然可以通过设置allowBeanDefinitionOverriding属性解决,但会引来新的问题)。 > 因此,容器必须解决这两个问题: > - 解决jar包冲突,通过自定义ClassLoader来实现,不同模块使用不同的ClassLoader进行加载。 > - 解决bean冲突,使用Spring Context进行隔离,每个模块对应一个Context,Context间可以有父子依赖关系。 但实际上我看了下源码,发现“通过自定义ClassLoader来实现”只是说给每一个单体服务分配一个classloader实例,每个单体服务本身就是独立的,只不过此处是将其部署到同一个JVM当中,这并没有和上文中“NoSuchMethodException”相对应。我理解的是NoSuchMethodException问题是出现在一个单体服务执行的一个进程中,如果这个单体服务本身存在多版本不兼容问题,JuShaTa并不能解决。 另外,spring context隔离,这个也是将多个服务独立了,本身就是单独的spring context,并且没有建立父子关系。 所以我感觉这个项目更像是在一个JVM中混合动态部署不同的服务,但并没有真正的做到对单体服务的类隔离及context隔离。 不知道我这么理解对不对,希望作者有时间可以解释一下,谢谢!

看了下代码,主要还是基于可编程式的SpringApplication com.didiglobal.jushata.springboot.JushataSpringBootModule ```` DefaultResourceLoader resourceLoader = new JushataResourceLoader(this.classLoader); SpringApplication app = new SpringApplication(resourceLoader, sources.toArray(new Class[0])); app.setBannerMode(Banner.Mode.OFF); app.setLogStartupInfo(false); app.addInitializers(new JushataApplicationContextInitializer(this.parent, httpPort)); app.addListeners((ApplicationListener) event -> { final String port = event.getEnvironment().getProperty("server.port", String.valueOf(httpPort));...

https://github.com/didi/JuShaTa/blob/c4d1ba331ed926c88af3665af80b68f98a38698c/pom.xml#L22 CVE-2018-15756 CVE-2020-5398 CVE-2020-5421 Recommended upgrade version:5.0.19.RELEASE

https://github.com/didi/JuShaTa/blob/c4d1ba331ed926c88af3665af80b68f98a38698c/pom.xml#L31 CVE-2020-8840 Recommended upgrade version:1.2.60.sec10

在使用容器加载后,原始的springboot的web项目中的server.servlet.context-path没有加上,而是直接使用了跟路径,为什么会这样呢?麻烦作者看到后回复