`
ieye
  • 浏览: 31663 次
  • 性别: Icon_minigender_1
  • 来自: 杭州
社区版块
存档分类
最新评论
文章列表
大多数java应用源码构建和依赖管理是使用maven来实现的,maven也是java构建和依赖管理的事实上的标准。我们的应用系统也都是基于maven构建的,maven虽然在依赖管理方面确实很牛叉,但是并不能很优雅地解决所有依赖的问题,比如此次谈及的“全局排除”功能。        之前包括现在都在经历这样的事情,想禁止一个依赖被依赖进来,如果这个依赖属于冷门的依赖,很少类库会间接依赖它,那么进行一次排除完全OK,但是如果一个依赖是热门依赖,比如常用的apache的commons系列工具库,单独排除也可以实现,只是比较啰嗦,而且以后引入新的依赖就要时刻关心是否会带来不被允许的依赖,对维护人员 ...
作为Java程序员,会经常碰到jar包冲突,特别是涉及到的外部依赖越多,冲突概率就会越大。由于我们的应用代码都是使用maven来管理的,所以依赖的解决相对比较容易。不过最近碰到的一个问题,确实经历了好多步才最终定位。 现象:应用启动过程中,spring容器启动失败,错误日志很明确,找不到CollectionUtils.isEmpty()方法,jar冲突的典型症状之一。       首先,确认了这个类是apache的commons-collections中的工具类(在eclipse中ctrl+shift+T或者command+shitf+T寻找CollectionUtils是来自哪个jar ...
Java日志系统确实比较丰富,常用的有log4j、JUL、logback等等,同时伴随着日志系统的发展,出现了日志框架commons-logging和slf4j。 简短地描述下日志发展,最先出现的是apache开源社区的log4j,这个日志确实是应用最广泛的日志工具,成为了java日志的事实上的标准。然而,当时Sun公司在jdk1.4中增加了JUL日志实现,企图对抗log4j,但是却造成了混乱,这个也是被人诟病的一点。当然也有其他日志工具的出现,这样必然造成开发者的混乱,因为这些日志系统互相没有关联,替换和统一也就变成了比较棘手的一件事。想象下你的应用使用log4j,然后使用了一个其他团队 ...
在业务系统中实现对已有的各个业务校验规则Rule的增强,因为太多的Rule实现依赖了外部系统而变得不可控,并且系统对规则基本定位成强校验,这样我们系统的可用性以及稳定性会被外部系统所左右,于是提出了对规则可以动态降级,实现运行时绕过一些规则的校验(当然,需要在业务容忍一致性和系统可用性之间权衡)。同事的想法:提供一个基类来负责执行是否降级的功能,然后每个具体的实现类继承这个基类,在执行真正的规则校验逻辑之前,调用父类的方法判断是否走校验。我觉得这样做的问题有两点,首先,规则本身不应该去关注降级的问题,这样规则的职责更加纯粹。其次,之前已经有很多规则实现,这样做要去改变之前的规则实现,而且是通 ...
代码中经常遇到这样的场景:对一个业务处理过程抽象出来一个接口,针对不同的业务有不同的接口实现,然后有一个管理这些实现类的类根据业务信息负责路由到不同的实现类。实现方式大同小异,大致方式都是如此。 class XXHandlerManager { private Map<String, IHandler> handlerKeyToHandler; public void setHandlerKeyToHandler(Map<String,IHandler> handlers) { this. handlerKeyToHandl ...
      随着IOC各种实现(比如Spring /guice )出现,特别是Spring的影响力的扩大化,面向接口编程范式被提出来,于是企业编程中便大量地使用IOC技术,典型的展现形式是一个接口对应一个(几乎全部是仅有一个 )实现,接口和具体 ...
Global site tag (gtag.js) - Google Analytics