J2Cache 2.3.4 正式版发布:整理对第三方库的依赖关系 - 开源中国社区
Float_left Icon_close
J2Cache 2.3.4 正式版发布:整理对第三方库的依赖关系
局长 2018年01月19日

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 正式版发布:整理对第三方库的依赖关系
分享
评论(17)
精彩评论
2
所谓的整理依赖,但是依然有问题。在跳过测试的情况下依然是无法打包完成的。仔细看的话会发现日志系统是混乱的,core、hibernate3、springbootstarter里面的Logger是来自slf4j的,但是hibernate4里面既有commons-logging的也有jboss-logging的,而且hibernate4依赖的spring版本也太老了吧,而且里面依赖了一个g:com.cloudhopper.proxool,a:proxool的依赖,会传递进来一些依赖,传递进来的依赖是使用的通配方式配置的依赖版本,最终导致对commons-logging的依赖版本出错
2
红薯版本帝~哈哈
最新评论
0

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

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

引用来自“红薯”的评论

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

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

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

引用来自“红薯”的评论

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

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

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

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

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

引用来自“红薯”的评论

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

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

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

引用来自“红薯”的评论

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

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

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

引用来自“红薯”的评论

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

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

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

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

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

引用来自“红薯”的评论

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

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

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

引用来自“红薯”的评论

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

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

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

引用来自“骨二”的评论

版本有点儿勤

引用来自“红薯”的评论

惊喜吧,意外吧,开心吧?��
太惊喜,太意外,太开心了:smile:
2
红薯版本帝~哈哈
0

引用来自“骨二”的评论

版本有点儿勤

引用来自“红薯”的评论

惊喜吧,意外吧,开心吧?��
@红薯 挺惊喜 挺意外
0

引用来自“骨二”的评论

版本有点儿勤
惊喜吧,意外吧,开心吧?��
0
版本有点儿勤
顶部