J2Cache 2.3.4 正式版发布:整理对第三方库的依赖关系

局长
 局长
发布于 2018年01月19日
收藏 5

红薯大大的 J2Cache 又更新了,现已发布 2.3.4 正式版,更新如下:

  • 增加 regions 方法获取所有缓存中的已用缓存区域

  • 整理对第三方库的依赖关系

  • 删除 DataLoader 接口,改用 Java 8 的 Function 接口替代(传递 key 参数)

  • 接口增加 get(String region, Collection<String> keys, Function<String,Object> loader)方法

详情请查看 https://gitee.com/ld/J2Cache/releases/2.3.4-release

J2Cache 是 OSChina 目前正在使用的两级缓存框架。第一级缓存使用 Ehcache,第二级缓存使用 Redis 。由于大量的缓存读取会导致 L2 的网络成为整个系统的瓶颈,因此 L1 的目标是降低对 L2 的读取次数。该缓存框架主要用于集群环境中。单机也可使用,用于避免应用重启导致的 Ehcache 缓存数据丢失。

本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动共创开源社区。
转载请注明:文章转载自 开源中国社区 [http://www.oschina.net]
本文标题:J2Cache 2.3.4 正式版发布:整理对第三方库的依赖关系
加载中

精彩评论

阿信sxq
阿信sxq
所谓的整理依赖,但是依然有问题。在跳过测试的情况下依然是无法打包完成的。仔细看的话会发现日志系统是混乱的,core、hibernate3、springbootstarter里面的Logger是来自slf4j的,但是hibernate4里面既有commons-logging的也有jboss-logging的,而且hibernate4依赖的spring版本也太老了吧,而且里面依赖了一个g:com.cloudhopper.proxool,a:proxool的依赖,会传递进来一些依赖,传递进来的依赖是使用的通配方式配置的依赖版本,最终导致对commons-logging的依赖版本出错
路小磊
路小磊
红薯版本帝~哈哈

最新评论(17

红薯
红薯

引用来自“阿信sxq”的评论

把hibernate4里面的每一个.java的文件打开来看了,import里面根本就没有用到和g:com.cloudhopper.proxool,a:proxool相关的类,除非直接写的完整限定名,所以是否考虑去掉这个依赖

引用来自“红薯”的评论

这些模块不是我做的,要不你提交个pr解决一下不?

引用来自“阿信sxq”的评论

已经提交了pr。源代码的目录结构根本不符合maven的结构,看着很不爽,简直是要逼死强迫症啊,能不能标准化啊

引用来自“红薯”的评论

简化了一下,不想要 maven 多了个 main 和 java

引用来自“阿信sxq”的评论

:cold_sweat:难道不应该走标准化的道路吗:confused:
没人说那是标准啦,只是一个习惯,j2cache比较简单,我希望目录结构也简单
阿信sxq
阿信sxq

引用来自“阿信sxq”的评论

把hibernate4里面的每一个.java的文件打开来看了,import里面根本就没有用到和g:com.cloudhopper.proxool,a:proxool相关的类,除非直接写的完整限定名,所以是否考虑去掉这个依赖

引用来自“红薯”的评论

这些模块不是我做的,要不你提交个pr解决一下不?

引用来自“阿信sxq”的评论

已经提交了pr。源代码的目录结构根本不符合maven的结构,看着很不爽,简直是要逼死强迫症啊,能不能标准化啊

引用来自“红薯”的评论

简化了一下,不想要 maven 多了个 main 和 java
:cold_sweat:难道不应该走标准化的道路吗:confused:
红薯
红薯

引用来自“阿信sxq”的评论

把hibernate4里面的每一个.java的文件打开来看了,import里面根本就没有用到和g:com.cloudhopper.proxool,a:proxool相关的类,除非直接写的完整限定名,所以是否考虑去掉这个依赖

引用来自“红薯”的评论

这些模块不是我做的,要不你提交个pr解决一下不?

引用来自“阿信sxq”的评论

已经提交了pr。源代码的目录结构根本不符合maven的结构,看着很不爽,简直是要逼死强迫症啊,能不能标准化啊
简化了一下,不想要 maven 多了个 main 和 java
阿信sxq
阿信sxq

引用来自“阿信sxq”的评论

把hibernate4里面的每一个.java的文件打开来看了,import里面根本就没有用到和g:com.cloudhopper.proxool,a:proxool相关的类,除非直接写的完整限定名,所以是否考虑去掉这个依赖

引用来自“红薯”的评论

这些模块不是我做的,要不你提交个pr解决一下不?
已经提交了pr。源代码的目录结构根本不符合maven的结构,看着很不爽,简直是要逼死强迫症啊,能不能标准化啊
阿信sxq
阿信sxq

引用来自“阿信sxq”的评论

把hibernate4里面的每一个.java的文件打开来看了,import里面根本就没有用到和g:com.cloudhopper.proxool,a:proxool相关的类,除非直接写的完整限定名,所以是否考虑去掉这个依赖

引用来自“红薯”的评论

这些模块不是我做的,要不你提交个pr解决一下不?
ok
红薯
红薯

引用来自“阿信sxq”的评论

把hibernate4里面的每一个.java的文件打开来看了,import里面根本就没有用到和g:com.cloudhopper.proxool,a:proxool相关的类,除非直接写的完整限定名,所以是否考虑去掉这个依赖
这些模块不是我做的,要不你提交个pr解决一下不?
老谭12345
我大奥思版本帝
阿信sxq
阿信sxq
把hibernate4里面的每一个.java的文件打开来看了,import里面根本就没有用到和g:com.cloudhopper.proxool,a:proxool相关的类,除非直接写的完整限定名,所以是否考虑去掉这个依赖
阿信sxq
阿信sxq
所谓的整理依赖,但是依然有问题。在跳过测试的情况下依然是无法打包完成的。仔细看的话会发现日志系统是混乱的,core、hibernate3、springbootstarter里面的Logger是来自slf4j的,但是hibernate4里面既有commons-logging的也有jboss-logging的,而且hibernate4依赖的spring版本也太老了吧,而且里面依赖了一个g:com.cloudhopper.proxool,a:proxool的依赖,会传递进来一些依赖,传递进来的依赖是使用的通配方式配置的依赖版本,最终导致对commons-logging的依赖版本出错
返回顶部
顶部