DailyRollingFileAppender是日志记录软件包Log4J中的一个Appender，它能够按一定的频度滚动日志记录文件。
如果您不熟悉Log4J，那我们建议您阅读一下 使用Log4j进行日志记录。
我们可以按下面的方式配置DailyRollingFileAppender：
log4j.rootCategory=INFO,file log4j.appender.file=org.apache.log4j.DailyRollingFileAppender log4j.appender.file.DatePattern='.'yyyy-MM-dd log4j.appender.file.File=run.log log4j.appender.file.Append=true log4j.appender.file.Threshold=INFO log4j.appender.file.layout=org.apache.log4j.PatternLayout log4j.appender.file.layout.ConversionPattern=%c %x - %m%n
在DailyRollingFileAppender中可以指定monthly(每月)、weekly(每周)、daily(每天)、half-daily(每半天)、hourly(每小时)和minutely(每分钟)六个频度，这是通过为DatePattern选项赋予不同的值来完成的。DatePattern选项的有效值为：
DatePattern中不用处理的文字要放到单引号(')中，如上面的(.)。如果您对此有疑问可以查阅SimpleDateFormat的文档。DailyRollingFileAppender中使用这个类来处理DatePattern。
DatePattern格式化之后的文本作为文件名字的后缀。DailyRollingFileAppender不支持格式化之后的文本作为文件名字的前缀。
DailyRollingFileAppender在每一个日志事件(LoggingEvent)附加(append)之前检查是否需要附加。也就是说如果在一个滚动区间中没有任何日志记录，那么这个区间的日志记录文件就不会形成。
查阅DailyRollingFileAppender的JavaDoc文档。
各种各样的行为都在产生数据，可以说我们并不缺少数据，缺少的只是记录的手段。
程序在运行的过程中也会产生大量的数据，幸运的是在这个领域我们并不缺少记录的手段。
如果您没有使用过日志记录软件包，那我们建议您阅读一下 使用Log4j进行日志记录。
在这篇文章中我们提到了日志记录的几个重要的用途：
Log4j是为Java语言开发的，后来被移植到了一些其它语言。现在Apache Software Foundation创建了一个Logging Services Project项目，目标是为应用程序提供跨语言的日志记录服务。
Logging Services Project中包括了：
除此之外，Sourceforge为我们提供了另外的两种选择：
我们相信这样的移植会越来越多的出现。
感谢开源！
Liskov Substitution Principle(LSP)
Barbara Liskov，一位女性计算机科学家。
The principle is :
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.
Dependency Inversion Principle(DIP)
The principle is :
A. High level modules should not depend upon low level modules.Both should depend upon abstractions.
B. Abstractions should not depend upon details.Details should depend upon abstractions.
Interface Segregation Principle(ISP)
The principle is :
Clients should not be forced to depend upon interfaces that they do not use.
Bertrand Meyer在 1988 年提出了 “开闭”原则，英文全称为 Open-Closed Principle，通常被简写为 OCP 。这是一条非常著名的原则，内容如下：
Software entities (classes,modules,functions,ect) should be open for extension,but closed for modification.
这一原则对开发软件实体提出了两个要求：
要实现这一原则的关键是抽象。
这一原则也告诉我们在学习设计模式时要思考两个问题：
回答这两个问题可以使我们决定是否使用一个模式。我一直认为模式是用来解决问题的。如果模式使用的不自然可能会给我们制造麻烦，这就得不偿失了。千万不要认为在项目中模式用的越多越好。
Eclipse 还差两天就 5 岁了。整个 Eclipse 社区都在祝贺，我也不例外。要了解详情来这里 Celebrate Eclipse's 5th Birthday 。
五年前，也就是2001年11月7日，IBM 第一次将 Eclipse 作为一个开源项目发布。那时我还只是在学校里使用记事本书写些简单的程序，全然不知一个优秀的开发平台已经诞生。Eclipse 进入我的视野是在2003年后半年，它为我管理开发过程中许许多多繁杂冗长的事情。感谢 Eclipse ！感谢 Eclipse 社区 ！
希望 Eclipse 能够越走越好！
相关背景：
1998年11月，IBM Software Group 就着手创建一个开发工具平台，这就是 Eclipse 的原型。
后来 IBM 意识到需要一个活跃的第三方来加快 Eclipse 的应用（事实证明这非常的成功），才决定在2001年11月1日将 Eclipse 开放源代码。
2004年2月2日宣布创建了 Eclipse 基金会。
这年头搞软件的都在说“可扩展性”，但是真正理解其含义的又有几人呢？
天天见一些技术总监和项目经理告诉他们的手下：这里要可扩展，那里要可扩展，那那也要可扩展 ... ...
天哪，原来可扩展性比客户目前的实际需求还重要。啊？谁说的，傻呀！没有人会这么说，但事情常常会做成这个样子。
当今的软件系统已经很复杂了，要能真真正正的实现客户目前的实际需求已属不易，何苦还要拼命的扩展那些空中楼阁之上的需求呢？
如果我是客户，我只会关心你们如何使我把目前的工作做的更好，而不是为我设计将来可能的工作方式。
多数技术总监和项目经理会认为充分考虑“可扩展性”可以更好的应对客户需求的变更。他们也知道“可扩展性”是昂贵的，但是他们心甘情愿。最可能的原因就是他们认为客户会无休止的变更需求。
需求是会变化和演进的，这是事实。但这并不是解释客户频繁变更需求的理由，这样的理由只有一个：没有真真正正的理解客户的需求。多花些精力来理解客户的需求吧！这比“可扩展性”便宜的多，而且更容易让客户满意。
软件是有生命周期的，像人一样也会成长，不要在一开始就企图设计它的方方面面。Brain Foote将其分成了原型阶段(Prototype Phases)、扩展阶段(Expansion Phases)和巩固阶段(Consolidation Phases)。
我赞同对合理的需求演进考虑“可扩展性”。合理的需求演进必须是能够证明的，而不是臆测的。
我比较喜欢 Erich Gamma 对于“可扩展性”的解释：
Bill Venners : By extensibility, what do you mean?
Erich Gamma : That you can customize behavior without having to touch existing code—one of the classical OO themes. You can reuse something adapted to your particular problem.
当今各种开源社区蓬勃发展，开源项目更是前赴后继层出不穷。这为我们提供了丰富的选择，不过其中也隐藏着很大的风险。因此在选择时必须非常谨慎。
您也可以向我们一样问问自己如下的问题：
通过一些查找，您应该可以得到一些答案。不过在最后决定是否使用之前，最好自己进行一下测试。
切记不要将自己项目的命运轻易的交给任何一个开源项目。否则只有哑巴吃黄连有苦说不出的份了。
